Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm designing a pretty standard Spring MVC application, and I'm trying to figure out where the responsibility for transaction management should lie.

I've been reading Java Transaction Design Strategies, and the one that I think best suits is the Server Delegate one, where the controller is what manages the transactions, and the services and DAOs are oblivious to the transactions.

Somehow, this doesn't feel right. My gut feeling is that the services are the ones that should control the transactions, but I have cases where a controller may call several services to perform an action.

How have you handled Transactions in MVC applications before, and where do you consider the best place for handling the transactions is?

share|improve this question
You want to move the transactions as high in the chain as possible. The entity managing the transactions should be aware of the process as a whole. Hence the controller is usually a good fit. – Andrea May 29 '12 at 14:41
up vote 4 down vote accepted

I find it useful to implement a Service Facade that decouples the implementation of services from the service contract. The Controller from the presentation tier (your MVC stuff) should be able to make a single call to a Service Facade, which then orchestrates the calls to one or more "service" objects/methods, and returns whatever the service contract says it needs to return.

In this architecture, the Service Facade would also be the place to hook in your transaction management.

share|improve this answer

It's my understanding that the controller should mainly be responsible for communicating with the business layer and preparing the view data when necessary. In that case, it shouldn't have any knowledge about transactions; they should be kept at a lower layer.

When the controller needs to execute some logic that consists of multiple steps where a single transaction would be desired, that logic should be rolled up into a method in the business layer. When managing transactions with Spring, you can easily define a service method as transactional, and how nested calls should handle their transactions: whether to pick up the existing transaction if available, always create new, etc.

share|improve this answer

The service layer is most naturally suited place for transaction demarcation in MVC apps no matter which service layer pattern you use.

However, sometimes concessions should be made for a specific application when it makes sense, so I would not be overly dogmatic about it. Just make sure that you use declarative transaction management so you can move transactions around to the most appropriate place without affecting your application code.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.