I hava class with set of another entity class as members e.g:


I persist newly instantiated class:

and can use persisted object later in another session after obtaining lock on object via session.lock()
but HibernateException: reassociated object has dirty
collection is thrown

this never happend if i call session.flush() before closing session which saves object.

In "Hibernate in Action" stated "...most applications rarely
need to call flush() explicitly". Why i have to flush session after persisting object?

Actually we think that most applications use 1 open session at a time for a tx, so flush is implicitly called.

but this is not true for in this case: SLSB + CMT (business logic)+ DAO (persistance)

bean method calls several DAO methods and container commiting tx after that.
but if first DAO call creates object, second - updates it...

I'm using Steve Ebersole's ThreadLocalSession which is fine for nested calls, but not appropriate for "parallel" ones

This pattern is safe for consecutive DAO calls (which is *not* parallel)

If your semantic is



Then it's fine, because there is no reason to call saveOrUpdate in such case on entities coming for daos

No semantic is:


only business objects passed between DAO calls, not session.
so i have to call save/update at the ends of DAO methods

The better way is to use single session in all DAOs, but if i implicitly call openSession()/session.close() what the point to use CMT tx, all nice declarative features are gone?
I want bean methods be clean of this low level persistance stuff as much as possible.

Usually, in this case, you should do

Your code is then portable outside a container and the flush is called, the tx management is delegated to the CMT.
You can also explicitly call flush in the closeSession, if you don't want to use hibernate tx api.

Still, what you do is a bad practice (IMO), you lost a significant amount of power given by hibernate by not sharing the same session.

In my original case, You can use AOP, session filter, EJB generation or whatever to handle the openSession, closeSession declaratively.
I consider that session mgt and tx mgt are 2 different things, so I'm OK with having declarative tx and non declarative session mgt.

PS: you should have a look at the EJB3 spec for declarative session magagement.

so hibernate tx manager delegate all transaction work to container if detects managet transactions?

Check the 3.5.5 chapter of the reference guide.

and what happend if i do not use explicitly hibernate tx manager?
i.e. do not


just rely on container managed transactions?
method calls still transaction guarded?

The connection is involved in the tx just as JDBC.

pardon my misunderstanding but does this mean yes or no?
do i need use hibernate transaction manager with cmt transaction?

Hibernate is not different from plain JDBC.
If you don't demark your tx on a CMT managed connection, the Tx is handled by the container. It is the same for hibernate.
Your method is then safe.

It is well explained in Hibernate in Action.