Where do I begin transaction and commit?

I have created this DAO class for my user. Should I begin a transaction and commit in that method or should it be outside of the dao?

You should begin the transaction before your "unit of work" starts. Typically this is outside of the DAO. Consider this example unit of work... you want to delete a user, delete their preferences and write a log entry to the dabase. These must all happen within the same transaction but would probably use separate DAOs for the different operations. Hence, start the tx outside the DAO in this case.

It sounds crazy, but it is true. Try this :

Transaction tx1 = hibernateSession.beginTransaction();
hibernateSession.load(myUser, oid);
myUser.setCredit(BigDecimal.valueOf(9999L));
tx1.rollback();

Transaction tx2 = hibernateSession.beginTransaction();
tx2.commit();

myUser will have credit 9999 saved to database!

This means where you begin the hibernate transaction does not matter, but the point you commit have to be after the object to get in a persisted state (not transient).

Let's make another try:

Transaction tx1 = hibernateSession.beginTransaction();
tx1.commit();
hibernateSession.load(myUser, oid);
myUser.setCredit(BigDecimal.valueOf(9999L));

that will not save the credit to the database.

The consequence of this test is that if you try to do multi-transaction, you have to be very careful.

This code isn't valid because when you rollback a tx you must close the associated session. This happens automatically on rollback when using thread base session management.

Thanks!

If the transaction shouldn't be in the dao how should I implement it in a nice way? Let's say I use Wicket with this. I dont want to access the dao's and handle transaction in a wicket class. Design question but how do you handle this?

There are many ways of course. Recently I've been using the springframework to handle my transaction management. Its simple, powerful, well documented and hence really popular. Great hibernate support too.

http://hibernate.org/42.html
http://hibernate.org/43.html

You do not need Spring, in fact, Spring makes everything more complicated when it comes to Hibernate Session management. Its Hibernate support is extremely poor (I really don't know why people think it isn't...) with legacy and outdated classes like HibernateTemplate and hard dependencies on the Spring framework for writing trivial DAOs (Note that these problems are typically the result of bad documentation and tutorials though, not inherently of the Spring framework design).

Where come your confirmation? Hibernate does not reject this code with any exception.

In the context of the Hibernate conversational session, this scenario could happen even one should avoid it. That's why one should not put transaction in the DAO.

From a pratical point of view, Seam is a better candidate than Spring for pure DAO stuff. Spring is too havy.

No, it does not happen if you designed your application properly because rollbacks are occurring in a catch{} clause somewhere, and the session is closed in the finally{}.

Thank you all. I think I got where the transaction should go!

I think that the transaction is the unit of work and not the session. so it is possible that in a session, you have n transactions and Ti rollbacked and Tj committed for i<j. So one unique "finally" cannot deal with this.

I know Hibernate does not handle by default this situation.

All I said is Hibernate does not throws any exception with multi-transactions if I leave hibernate.transaction.auto_close_session to its default value as the Hibernate reference document suggested.

Of course it works just the same way if you have multiple transactions over one session! If one of the transactions rolls back, the session is closed, conversation is over, fine.