Hi, I'm new to Hibernate. Using version 3 and having the following issue-

I'm building out from my data model and running unit tests via JUnit via Ant.
I used the Hibernate tools for eclipse to generate my model classes and DAOs (side question - the tool generated all of the DAOs named PersonHome, AddressHome. Why not PersonDAO, etc?).

When I ran my first unit test, I got the following error:


So I did a google search and added this line to my hibernate.cfg.xml:


After that, I got the following error when trying to persist an object:


Very well, i suppose that makes sense, an insert is an unsafe operation.

So i began and commited a transaction around my persist as such:


Success!, however, I'm now getting the same error when I'm truing to retrieve that very record:


So, my questions are:

• what is a CurrentSessionContext? I supplied the value "thread". what does that mean? What are the other options?
• I'm guessing that all session operations that access the DB must be part of a transaction? The persist makes sense, but why the get?
• If, indeed, all operations must explicitly be part of a transaction, then why did the Hibernate tools code generator not put that in my DAO as well?

Sorry for the long post. Thanks for any help!

# I'm guessing that all session operations that access the DB must be part of a transaction? The persist makes sense, but why the get?

Indeed. This is always true, but sometimes JDBC connectors hide this reality from us.

A transaction is very appropriately defined as a "unit of work." If going to a database and getting data isn't a unit of work, I don't know what is. Of course, people often associate a transaction with ACID properties, and think that a transaction goes hand in hand with a change of data and a possible rollback. But regardless if you are just reading or if you are updating, you're doing work, and that must happen in a transaction.


# If, indeed, all operations must explicitly be part of a transaction, then why did the Hibernate tools code generator not put that in my DAO as well?

Well, doing so would walk you right into the transaction-per-operation anti-pattern. If each update, get, save or delete method starts and stops a transaction, well, then you'd have alot of transactions. Often you want multiple operations to work within a common, rollback-able, transaction. You may want to update one column, delete from another table, and save to a log table, and if any of this fails, you want the ability to roll it all back. If the begin and commit semantics are within the same DAO method, each method call would be atomic, and that's bad.

The Hibernate code manages how the client application marshals calls back and forth to the database layer. However, how transactions are demarcated should be left to the client, so inteligent decisions can be made about how various pieces of data should work together within the scope of a single, ATOMic trasaction.

I have a little tutorial on my website that discusses how Hibernate works which you might find interesting. Check it out.

http://jpa.ezhibernate.com/Javacode/learn.jsp?tutorial=07howhibernateworks

Good questions!

Hi Cameron-
Thanks for your post. I took a look at your site - it's excellent. I will certainly be referencing it more as I go through this project.

I guess what's throwing me off is, as far as I understand the DAO pattern, all details of the transaction should be encapsulated in the DAO itself. It seems that Hibernate suggests otherwise, both by the way the DAOs are generated by the eclipse tool, and in the Hibernate documentation itself. See http://www.hibernate.org/328.html. In all three examples, the controller handles the transaction as well as the manipulation of the DAOs

Isn't it great when you're mind is exposed to a new way of thinking? And if you think the way we deal with DAOs is interesting, just wait until we blow your mind with the Open-Session-In-View design pattern. :)




Well, I've seen that quite a bit in the past, and I've seen alot of EJB implementations implemented in just this way. But it creates a very large number of transactions, and really handcuffs the developers who are using the DAOs.

What's the point of the DAO? It's really to make it easy for the application developer to interact with back end data, while at the same time, hiding the implementation details. Really, DAOs hide the plumbing that is behind the scenes. But what they shouldn't do is restrict how the data is used. By demarcating transactions behind the DAO methods, you have essentially decided for all of the people using them when a unit of work begins and when it ends. There are often very compelling reasons to have longer transactions, or have multiple DAOs particiapte in transactions. Having a DAO method cut off the transaction as it finishes really takes the power away from but people who will be using them to implement business logic.

Plus, what if your transaction manager changes? A client using the DAO may use a HibernateUtil class to demarcate a transaction, but what if that changes to the J2EE UserTransaction object. The people using the DAOs can decide this. If the transaction details are inside the DAO, the solution becomes much less flexible.

But you are correct - the way Hibernate and Spring and most of the other young show-offs demarcate transactions is outside of the DAO, in the business layer, not the data layer.

The problem is with sessionFactory.getCurrentSession()
instead use sessionFactory.openSession()

Using openSession is extremely dangerous if you don't know the implications of using an openSession.

openSession is effective if the client application is managing the Hibernate Sessions itself. So, if you have written a program to do your own Hibernate Session management, you're good. But I have only known a few implementations that found this necessary, and conversely, I have many people use openSession without understanding the difference between getSession and openSession, and this has caused many problems.

Use the right tool in the right spot, but you definitely don't want to be opening a new Session every time, unless you have the state management aspect implemented to maintain a reference to those opened Hibernate Sessions.