What is the purpose of continuing Hibernate I/Os when EJB CMT has already timed out? checkTransactionSyncStatus() only terminates with a SessionException if the session is closed. If the enclosing transaction has timed out, that fact is ignored until hibernate I/Os are completed. Is there any reason it should not detect that the transaction is marked fro rollback and throw an exception at that point?(JTAHelper.isMarkedForRollback()).
I would really appreciate a reply so I can understand or supply more information or make adjustments if we are doing something incorrectly..

Environment Information:
WebSphere Server 8.0, using EJB 2, Container Managed Transactions and configured with:
- a 3-minute HTTP session timeout value
- hibernate.transaction.factory_class=org.hibernate.transaction.CMTTransactionFactory
- hibernate.transaction.manager_lookup_class=org.hibernate.transaction.WebSphereExtendedJTATransactionLookup
Hibernate 3.2

Scenario:
While persisting a large number of rows, Hibernate did not seem to realize that a WebSphere (WAS) transaction was going to roll back so Hibernate kept working for a long time (persisting many hundreds of rows) until it was complete.
Upon Hibernate’s completion, the status of the transaction was checked and all updates were rolled back properly. Intermediate flush() statements were in place.

Issue:

Since the 3-minute timeout was not honored, the actual request now spanned over 7 minutes, causing timeout issues in other applications interested in accessing the data, due to application-specific “locking” mechanisms in place.

Questions:

Should Hibernate react to checking the status of the transaction upon a flush() action for a transaction timeout?
If not, what can be done to communicate the timeout to Hibernate?