meaning of a session.startTransaction()

[Alarmnummer]

I`m trying to understand more of the behaviour of transactions and sessions in Hibernate. And we where experimenting with the following:

session.saveOrUpdate(object1);
Transaction t = session.beginTransaction();
session.saveOrUpdate(object2)
t.commit();

After the commit, object1 and object2 are both committed to the database. I find the strange, because object1 is not part of the transaction but it is committed. Is this the default behaviour of a Transaction?

[dejanp]

I don't think you can have two transactions with one session really. If you use pure JDBCTransactions begin() simply sets autocommit to false. When you commit(), you get everything belonging to the session flushed and commited.

[Juergen Hoeller]

That's standard behavior of a Hibernate Session, odd as it seems. The Hibernate Session registers objects to be flushed at some later time. When you call commit, everything in that Session is gonna be flushed - all state getting synchronized with the database, even for objects that have been registered before the transaction started.

Essentially, the transaction only refers to an underlying database transaction. The central place (and granularity) for state management is the Hibernate Session, not the transaction. Of course, that distinction doesn't matter if you're following a typical rule: one Hibernate Session per transaction.

That said, I would recommend to keep explicit transaction management out of your data access code. Your data access objects should be able to participate in existing transactions that the caller opened. Prefer declarative transaction demarcation at the service facade level, either through Spring transactions or through EJB CMT.

Juergen

[Alarmnummer]

That's standard behavior of a Hibernate Session, odd as it seems. The Hibernate Session registers objects to be flushed at some later time. When you call commit, everything in that Session is gonna be flushed - all state getting synchronized with the database, even for objects that have been registered before the transaction started.

Ok

That said, I would recommend to keep explicit transaction management out of your data access code. Your data access objects should be able to participate in existing transactions that the caller opened. Prefer declarative transaction demarcation at the service facade level, either through Spring transactions or through EJB CMT.

We are experimenting and trying to understand what the relation between a hibernate session and a Transaction is. The example is no production code.