AOP实现事务控制的疑惑

最近接触到AOP,想用其来实现事务控制,避免在很多地方写重复的事务控制的代码.
我的大概想法是这样的:在Service以外实现事务控制.由于目前使用了Struts2表现框架,于是想把事务控制在Action这一层实现.借助Struts2的Interceptor,很快的写了个事务控制的类.此时有个问题困住了我.比如在Action1中调用了两个Service(Service1,Service2)的方法(Service1.add(),Service2.add()),如果Service1.add()执行成功,但在Service2.add()中抛出了业务异常(并不是什么系统异常,比如是用户填写的东西不符合什么规范之类的业务逻辑),此时我在Action1中肯定要捕获这个业务异常,返回给客户一个提示信息页面.但是为了回滚事务,我要抛出个异常让Interceptor捕获,好回滚事务.但是一旦让Interceptor处理了异常,其后的页面转发就成了问题.
问题1.我想让Action来决定显示的页面,而不是让Interceptor来决定.(因为Interceptor在Action之上,所以只能做一些公共页面的转发).
问题2.在Action处理业务异常后,不得不考虑到为了回滚事务,要向Interceptor抛出异常,我感觉这样没有达到我先前的预期,也就是在Action这里可以不用考虑事务.
希望大家指教

[该贴被power1128于2008-04-10 15:15修改过]

>于是想把事务控制在Action这一层实现
设计思路完全错误,事务只能是在业务层或持久层实现,不要在Action中放入太多代码,见最近有关Action的讨论。
http://www.jdon.com/jivejdon/thread/33821.html

Struts2的Interceptor简直是诱导初学者犯罪,范设计上分层的错误,Struts2误导性的东西太多了。

[该贴被banq于2008-04-11 10:19修改过]

banq大哥,我对事务在Service层实现还有疑惑:
比如现有两个Service,Service1和Service2,它们在自己的服务里实现了事务.
此时又出现Service3,Service4,并且在Service3或者Service4中调用Service1或Service2的服务,并且有自己的事务要求,那么这里可能出现事务嵌套.
所以我感觉在Service实现事务控制并不灵活,而且可能导致大量的事务嵌套,我觉得这种嵌套是没有必要的.那么为什么还在业务层实现事务呢?
以上只是我的想法,请各位指教.

你可以看一下Spring和EJB3的应用层事务实现。他们通过声明式事务实现了事务处理。缺省事务策略下是当一个Service调用开始的时候,如果没有事务,则启动一个新事务,如果已经有事务,则在这个事务中执行。根本不会出现你说的嵌套问题。

不存在事务嵌套的问题~ 数据库的实现就不可能出现这个问题~~~~,什么是事务你没弄懂
映射到的持久层怎么又会有嵌套呢

>感觉在Service实现事务控制并不灵活,而且可能导致大量的事务嵌套
JavaEE标准中就有一个很著名的组件JTA来解决事务的,这些问题都是有JTA组件去解决,这个JTA已经非常成熟,应用在EJB多少年了,Spring也是用JTA的,你不用担心这些细节问题,Java的缺点就是太成熟了。

原来JTA的原理是这样的.虽然我也用了JTA,但对它的实现细节还不了解,多谢banq 和wlmouse 的指点.

[该贴被power1128于2008-04-15 12:39修改过]

同意wlmouse的说法。你可以通过声明来控制事务属性的,并且你可以控制不同的服务在同一个事务中,你也可以控制不同的服务进行事务嵌套。EJB这方面做的非常好。