I've been reading up a little on the DAO pattern, and i believe i have a fair grasp of what is being written about this pattern on the Hibernate site (https://www.hibernate.org/328.html). However, one of the things that is being written is that DAO's should never deal with transactions and sessions. How do i then handle transactions?

Say that i obtain a UserDAO from a DAOFactory, which sets the currentSession() through a setSession() method on the UserDAO. Now, i would like to delete a user. This means that i need to start a transaction, and then finally commit. However, as far as i can see - i'm need to control the transaction outside the DAO - in my Business Logic. This is because the DAO should not have anything to do with the transaction, and then i guess the Business Logic Layer is the only option left as to where i can control it from? So, then i've suddenly put Hibernate specific code, which i though should be in the Data Access Layer, into the Business Logic Layer.

I couldn't really find much anywhere else on this, so i really hope someone out there have the chance to enlighten me and give a bried description of how transactions should be dealt with - in a way which really separates Data Access from Business Logic.

Please note that this is not a question about how to use transactions and sessions in general (that i know quite well), but a question about how transactions should be used when i try to adhere to the DAO pattern.

DAOs are like actors in a play. But the script is written elsewhere. If you want three databases to be hit in one transaction, and have all three databases rolled back if something fails, you can't do that if each database starts and ends their own transaction.

So, DAOs give you the fine grained access. Something else must coordinate that. That 'something' can be anything, but it is often a stateless session bean (see session facacd) or even a filter type of component implementing an 'open session in view' pattern.

Here's a little tutorial on advanced DAO mapping if your'e interested:

http://jpa.ezhibernate.com/Javacode/lea ... vanceddaos

Thank's a lot Cameron for your reply.

I've been reading a little about DAO patterns and Session Facade patterns, and if i understand what you say right, then i could approach it the following way:

1. Create a DAO for each of my entity beans.
--> See: http://jpa.ezhibernate.com/Javacode/lea ... vanceddaos

2. Create session facades which groups persistense operations in a logical way. All usage of the DAO's happens in session facade objects, and the Session Facade is thus a natural place to control sessions and transactions as the facade groups operations. An important point is that the DAO's themselves should not be exposed directly in the business layer - but rather the session facade should offer "services" to the business layer.
--> See: http://javatechblues.blogspot.com/2007/ ... ttern.html
--> See: http://www.ibm.com/developerworks/websp ... cades.html

3. Business Layer will use the "services" offered by the Session Facades.

After all i've been reading, that's what i make up of it. Does it make sense, or am i doing some really grand huge mistake here?

Indeed, I think that's very much the most common approach to using DAOs in an application. I've often heard the idea that Session beans should be like a script, co-ordinating your actors, and the DAOs are the actors themselves. So, the Session Bean can choose which ones to invoke and how to apply transaction management and how to isolate reads and updates.

Speaking of DAOs, I just finished a good discussion on whether the DAO pattern has been made obsolete by the existence of JPA persistence stores. It's an interesting read.

http://www.coderanch.com/t/458380/Archi ... ssion-bean

Kind regards!

I should also mention, that despite the name of the thread, I don't believe DAOs should be implemented as Session Beans!