You probably do not want a Transaction in View type of functionality. Typically what happens on a request is
- request comes in
- invokes some operation that saves stuff to database
- response goes out. i.e. render the success page or return json or whatever
The reason you dont want 'transaction in view' is because if there is an error at step 3, your transaction will be rolled back, even though the the actual business logic was successful, only rendering the response failed.
Now, I have made the assumption that you want the data to be committed even if there is an error after you commit it. If that assumption is false, then ok, thats up to you.
Since service methods are wrapped in transactions, perhaps an easier solution to your problem is to refactor your code such that one service is called per incoming request. Typically this is called the 'facade pattern'. Lets say you have
Service1.op1()
Service2.op2()
and you call both those methods for one request. You could simple create another service
AppFacade.doOp1andOp2()
that invokes op1 and op2 on the relevant services.
Another possibility would be to configure Spring to put transactions around your Struts Actions with declarative transaction management. Note with transactions, from the time the tx is open, to the time it closes, all db operations will use that same transaction, so even if you call multiple services, they all use the same tx.=. See the documentation here:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html
specifically 10.5.2
But I think using one service call per unit of business functionality is the best approach.