In the transaction-per-session scenario (or even otherwise), what happens if you flush the session and then the transaction has to be aborted?

I think this should be rolled back as well. What counts is when the rollback occours in the database.

Its not clear why you would want to flush the session in the middle of your processing? Looks like the only time flush is needed is before commit().

A related question: when you do a hibernate query, is the updated data in your session available to query if you haven't done the flush() yet?

It should be able since a query triggers a flush, unless you specify something different.


For most scenarios this is true. But if you have code that for instance needs an id created by a sequence before the transaction ends you will have to flush earlier.

Actually id generation is not a good usecase since it gets generated right away (no flush needed).
But working on massive amount of data in a single transaction or early catch of optimistic locking issue is.

> But working on massive amount of data in a single transaction or early catch of optimistic locking issue is.

I understand the need to flush (and clear) while working on massive amount of data in a single transaction ... to keep your session memory/cache limited.

Why do you need flush for optimistic locking?

This is an interesting point. In a recent project we needed to flush earlier due to ID not being generated right away. I'll check that with a small test case on my box...

it can be the case for persist if you are out of transaction. But if you are out of tx, you don't want to flush

Of course. Actually in a small test case and in our full app ids get assigned after calling save.

Sorry, Emmanuel you were absolutely right. We are flushing earlier for calculated values which have to be stored in the db and have to be passed to the DTO mapper. Calculation is being done by Interceptor#preFlush()...

I think I have to reread my JB world berlin slides because I remember having early flushes in them. Thanks a lot!

Actually I found a use case regarding ID generation where you need to flush earlier in order to get the id:

ObjectA references ObjectB in a <many-to-one cascade="all" ..> relationship.

Initially ObjectB is not saved. After loading ObjectA from the database using session.get(..) I create a new ObjectB and add it to object a without calling session.saveOrUpdate(objectA).

In this case ObjectB get's the id upon calling transaction.commit() and not right away.

ah yes, transitive persistence requires a flush