What is the purpose of Managers / Transactions?

Question

I'm building a spring application for the first time. I'm running into lots of problems with concurrency, and I suspect that there is something wrong with the way I'm managing the backend. The only difference I can see between my backend code and examples I've seen are manager classes.

In my code, I have my model (managed by hibernate) and my DAOs on top of that to do CRUD/searching/etc on the models. In example code I have looked at, they never use the DAO directly. Instead, they use manager classes that call the DAOs indirectly. To me, this just seems like pointless code duplication.

What are these manager classes for? I've read that they wrap my code in "transactions," but why would I want that?

Hudnall

can you post an example or a link to an example where these managers are used? – Setter

Answer 1

Transactions are used to make updates "transactional".

Example) A user clicks a webpage that leads to 13 records being updated in the database. A transaction would ensure either 0 or 13 of the updates go through, an error would make it all roll back.

Managers have to do with making things easier to do. They will not magically make your code threadsafe. Using a DAO directly is not a thread safety bug in and of itself.

However, I suggest you limit the logic in your DAO, and put as much logic as you can in the business layers. See Best practice for DAO pattern?

If you post maybe a small example of your code that isn't working well with multiple threads, we can suggest some ideas... but neither transactions nor managers alone will fix your problem.

Ataraxia

Long running transactions often appear to be "concurrency" problems as the other threads hit the (database) locks of the open transactions. – Fulmer

Very true. Need more details to see if that is what he was referring to as problems – Ataraxia

Answer 2

Many applications have non trivial requirements and the business logic often involves access to several resources (e.g. several DAOs), coordination of these accesses and control of transaction across these accesses (if you access DAO1 and DAO2, you want to commit or rollback the changes as an indivisible unit of work).

It is thus typical to encapsulate and hide this complexity in dedicated services components exposing business behavior in a coarse-grained manner to the clients.

And this is precisely what the managers you are referring to are doing, they constitute the Service Layer.

A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.

Odalisque

Answer 3

DAOs should not own transactions, because they have no way of knowing whether or not they're only a part of a larger transaction.

The service tier is where transactions belong. You're incorrect to say they're a "pointless code duplication."

Pumphrey