Currently the implementation of SessionImpl.doFlush() starts with
private void doFlush() {
checkTransactionNeededForUpdateOperation();
pulseTransactionCoordinator();
I think this might be in the wrong order.
checkTransactionNeededForUpdateOperation() will throw a TransactionRequiredException because TransactionCoordinator.isJoined() returns false. (checkTransactionNeededForUpdateOperation -> isTransactionInProgress() -> transactionCoordinator.isTransactionActive() -> isJoined())
The TransactionCoordinator however will join the transaction (if possible) in the call to pulseTransactionCoordinator().
I am debugging our application which has a problem right there. It is a Spring 4.3.25 with JTA where I’m trying to upgrade Hibernate from 3.x to 5.4. Obviously it uses the Spring OpenSessionInView and probably a bunch of other things which could be improved upon. Spring’s special hibernate session context handler introduces a transaction synchronizer which calls flush on the already open session. During the web request at least 1 transaction was processed, which did some hibernate calls. But the second transaction fails. This is mostly due to the fact no other Hibernate Session method was called which does the pulseTransactionCoordinator(). If I simply add the session.isConnected() to one part of the code, that whole process works. (Which is obviously a dirty hack which I cannot apply to the whole codebase.)
So it feels like those two method calls in doFlush should be switched around. In that case if there is a transaction, the session will auto join and the call to checkTransactionNeededForUpdateOperation() will succeed. If there was no transaction, the latter will still raise the exception.