Transaction demarcation code has no place in a DAO. I've explained this already in this thread and don't want to do it again.

It's really really trivial to extend this class with a few lines to support several SessionFactories. All you need is a getSession(String persistenceUnit) method. Maybe you want to try it yourself this time?

Christian,



I wasn't making a point or asking about transaction demarcation at all. But speaking about
transaction demarcation in DAO

http://cvs.sourceforge.net/viewcvs.py/hibernate/CaveatEmptor/HiA-SE/src/java/org/hibernate/ce/auction/dao/hibernate/GenericHibernateDAO.java?rev=1.5&view=auto

shouldn't HibernateUtil.beginTransaction() calls go away from DAOs in CaveatEmptor (GenericHibernateDAO.java)?

Don't get me wrong the reason I'm posting here is a wish
to have CaveatEmptor code usable for more people and to share
experiences with it.

Regards,
--MG

There is a reason that beginTransaction() is there. Because it just joins any ongoing transaction. If none exists, it starts one. This is called "lazy" behavior, something that is very well documented in everything that was linked to in this thread. It's also very optional. I'm not sure I like to continue this discussion at this level.

And yes, your suggestion to make getSession() a method to override is a good one and I'll think about it.

Returning to the beginning of this thread. It wasn't totally trivial to debug or trace the error which resulted in net.sf.hibernate.HibernateException: Session is closed. Therefore it might be reasonable to do this:

It's easy to make the (somewhat abstract) mistake of closing the session and simultaneously not committing the transaction. But I'm reluctant to add 'own' functionality to the HiberateUtil which would throw exception in this situation -- partly to be able to use the next official version of the HibernateUtil 'straight out of the box'.