Here is a block of code in the Java Persistence with Hibernate book by Christian and Gavin, it's from the conversation chapter,




I am confused that why the first step and second step need to be wrapped into two separate transactions? Since the flushmode is set manual here, no operations (suppose we ignore the insert here) will hit the database anyway. So what exactly happens when session.getTransaction().commit() is called when session's flush mode is set MANUAL?

thanks

session.getTransaction().commit() propagates a commit on the database.
The database must commit its transaction although there were no DML SQL statements at all, which means committing an empty transaction.

This kind of conversation in my eyes is a trick to span a conversation over more transactions,
getting some ACID aspects valid for the whole conversation.

What's a little confusing in this chapter, is that the reader is asking himself:
why do call commit on a empty transaction (nothing flushed) at all?

The answer is probably, that in a typical EJB conversation you don't have direct control over commit at all
because there you will use declarative transaction demarcation instead to programmatic transaction demarcation.
It is in this context which the delay of the flush until the last step of the conversation makes sense.
This is at least what I understood from this chapter.

Thanks for your clarification!

In particular, it is presumed that there is some sort of user interaction (with a potentially unbounded human reaction time) between the two steps in this conversation, and that's why they can't be in the same transaction.