关于Action的事务

这个问题的关键在于：事务加在哪层合适了？
dao，service还是action，你都试试，最后你会发现加在service是比较合适的

当然不是绝对的，至于事务怎么加？aop式的声明式还是编程式事务

这个是看你框架怎么设计的，那种都可以，那种在什么场合合适

好的设计是可以规避问题的

我比较统一楼上的观点。dao层是比较细粒度的层次，servie是在这些细粒度的层次上进行的业务逻辑整合~~~比如说一个工单的流向涉及到很多其他业务表的增、删、改操作。这时候就比较适合在service层将以上业务逻辑做成一个整体事务性粒度。而如果在Action层的话，可能（当然我指的是大多数应用了啊~~~）不太合适~~~因为Action算是web层与调用业务层的桥梁，他除了调用业务接口还需要负责接收web组件的值啦、根据业务逻辑的返回结果决定返回视图啦等等这种不需要事务的操作，遇到异常了，可以直接向上抛异常即可，web容器，或者更重量级的容器会根据异常告诉视图层的（虽然这种异常处理在用户体验上不是很好啊~~我在这里也是仅仅举个例子）。
说实话原来我也想过，估计其他很多人也想过，在Action层配置事务，后来根据经验确实觉得service层是最适合集成细粒度操作的事务层~~~
还有就是LZ不必介意那些对你造成伤害的回复，你敢提出质疑，就证明你有去读开源项目源代码的勇气、而且没准儿还能做出个开源项目出来！

    我觉得都能向楼上那样回复别人的问题就和谐了。事务确实加在service层比较合适，但本身service这个层次的划分，大多是在数据库操作基础上对业务的封装，是一个逻辑上的概念，而我们不必纠结于逻辑上的代码划分，假如你需要在action这一层来事务控制，也是可以的，因为事务的控制本来不该被所谓的各种层次限制，假如你某个action需要事务，那么你仍然可以加，至于怎么加，不一定非得spring什么的。我现在自己用的一个小框架，在实现action的时候，我会判断本类是否包含事务注解，假如包含，则在工厂生成一个代理类，那么当action（或者任何包含此注解的类）在调用相应方法的时候，会被代理，并在前后加上事务，当然，实现方式还有很多种，希望lz可以想清楚，重要的是这个问题要独立一些所谓的框架来想，不然会自我设限。

LZ,你们是正式开发吗？如果是正式的话，应该有规约吧。。。。虽然对事务控制放在哪都可以，甚至可以 open session in view ，但是要考虑其合理性和必要性。个人觉得，spring 的控制已经很好了，如非特殊需求，够了。

谢谢几位的答复，我也认为在service层使用事务最好，Action只是负责收集数据并验证数据，没有对数据库进行增删改不必要进行事务控制；可能是我开始表达不够明确，呵呵，我现在是在研究不使用Spring怎么在service上进行事务控制，不想局限于Spring的AOP。Google上百度:)出来JTA是java事务的API，不知道使用JTA是否方便。

http://suhuanzheng7784877.iteye.com/blog/908380

希望对你有用~~~JTA算是JavaEE的事务接口规范~~~具体的底层实现可以不同~

做人不要太那个了。。。。。。、

谁都是从不懂到懂的一个过程，兄弟你也不是一出生就天生懂java，如果你绝对楼主很菜，你可以不回答，但是这样羞辱新人，是不厚道的！

既然用了SSH，那么内层的分工都是明确的，struts只作为控制页面逻辑用，与业务逻辑无关，所以一帮action只负责接受页面的参数，并转化为serivce层需要的数据格式，并提交给service处理；或者接受service层返回的数据，并将数据转化为页面需要的数据格式并返回给页面。

service（Spring控制）层做业务逻辑，一般这层需要是事务控制，

DAO层（hibernate）就是持久了，没的说了。

我知道自己不厉害，但看见这位北大青鸟出来的就知道用在北大青鸟学的Spring，还自大，很无语。