有没有人在struts2的action这一层办事务控制

可以考虑open session in view  用struts2的intercepter

web层主要的作用是获取request中的数据,组织好交给service来处理，再然后处理service返回来的结果
也就是说web层起组织数据和处理结果的作用
而不应该用几个Business Service组成什么流程，这个流程应该在web层之下来完成

另外：dao在不是特复杂的项目里面跟本没必要保留，直接service会大大提供生产效率。

不需要单独一层啊，有时候提供一个粗粒度的方法就够了。我建议业务层的每个子模块里只有极少量的Service类，每个负责一大组相关的业务，接口都足够的粗。Service类实在太大了之后，可以重构出一些内部类，但出口仍然是Service的粗粒度接口。

Action无论如何，不可以调度同一事务内的多个业务方法这条约定我觉得是还是必要的，否则就很容易像你说的把业务逻辑直接写在Action里。而且，遵循这条约定其实不难。

嗯，其实这也是我以前一直的做法，只是现在team人比较多，不太容易说服所有的人，或者说保证所有的人
都这样做有一定的风险。
现在已经用拦截器的思路实现了，有了这一层的保障，再尝试用规范约束吧。

按照楼主的情况还是考虑用sturts2 interceptor吧，现实往往是残酷的。

两种可能:
1.您的需求确实很复杂,需要这么实现.
2.您没有弄清楚为什么在dao层上面有个service层,service层是干什么用的,于是把service层当dao.又在上面套了一层,很不幸的把action控制层当成了它.

在action里调用 service1(),service2()..
这种情况不就是在action里写了业务逻辑了吗,为什么要先调用service1后service2,一个次序,service2也许还要使用service1返回的结果做参数?
这不就是业务逻辑吗/.

你可以action里调用一个service(),service()里封装了，你要操作的service1，service2，然后对service()加事务的操作！

很奇怪楼上这么多位居然从来不复用Action吗？
虽然Action本身没有很多的逻辑，但是能简单责简单，既然有了现场的功能就不需要另外开发了，在已经有了A，B两个功能后，用户提出了在某些时候操作完A后会立即使用A的数据操作B，但是来回切换太麻烦，因此要求将A和B另外组成一个界面，但是后台的逻辑没有任何改变，在这个背景下我们发现通过ActionChainInerspector可以完成这个功能，而且所作的改变仅仅是重新根据A的view和B的view合成一个新的View（当然还需要加上事务控制也就是楼上诸位在讨论的东西），我想使用Webwork的极致就是这样了吧，这也是我们一直苦苦追求的高度复用，webwork的确不愧是一个框架时代的终结者。

再多补充一点，当Action层切分的足够细，足够原子，就会发现把他们进行组合复用其实是非常简单，非常的合乎自然语法，例如将一个又一个的对象在页面间甩来甩去，任意的对他们进行糅合，多么奇妙的体验，感觉离程序员追求的终极目标又更近了一步。

我不知道你为什么要在Action进行事务处理，不过从分层编码的要求来说，你这种做法是很不合理的。
你应该把事务控制交给Spring进行管理。
Spring进行事务管理根本不会像你说的那样没有办法用，你只用把Spring的Bean注入进来就可以速正常进行使用啦。

加 spring 做，，很爽

action里当然不应该有业务逻辑和事务控制，原因很简单,action里import了http相关的类，和协议绑定了，如果在action里放业务逻辑和事务控制的话，非http的请求就不能复用业务逻辑和事务控制功能了，所以中间再加一层是对的。
比较好的方法是在action里创建一个工厂，由工厂创建一个Handler，将httprequest里的数据转换成一个和协议无关的通用数据结构，传递给Handler,使用哪个工厂和具体Handler实现，在xml里配置就可以了。
然而Handler里可以仍然没有业务逻辑和事务控制，它只是个代理或外观模式，作用是做BO的缓存，并提供一些管理功能，如交易统计、访问日志、服务的开关、错误处理等，它调用的service可能是访问本地文件、数据库、邮件系统、外部系统、异步调用等等

在action层调用service层逻辑，在service层进行事务控制

如果有必要在action做事务控制的的话
只能说action中包含了比较多的业务逻辑吧。
我也比较同意sevice提供粗粒度方法。
action简单做些传值就好

和楼主有同样的问题．
spring的声明事务在action中会出错．

关于action的业务逻辑嘛？
假设在actiont中有这样的流程

serviceA.createA();
serviceB.createB();

即不适合在servicA中createB也不适合在serviceB中createA．或者在servicC中createA和createB？
那也许并不比在action中createA和createB合适．

XMLDB 提供的代码不全吧
import com.wolfsquare.core.Application; 找不到．

楼主能否提供完整的代码呢？

我支持在多个Action中的调用中使用Action级的事务控制方法，如果仅仅是想解决同一个Action里调用多个Service的事务问题，还是建议封装一个统一的Service。

那是你的Service颗粒度有问题吧。。

Action根本就不该重用。

同意楼上的，action不应该重用，action实际应当是对应到一个页面的某个动作的。
如果说一个挥手的动作，你是用一个单一的挥手Action呢还是分解成抬手Action挥Action，停止Action等等一系列Action？
这些动作分解还是放到Service中来做吧！