Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
31 of 31

TM Transaction timeout handling in Hibernate does not handle remote (ejb) invocations

Out of Date

Description

When we added Hibernate transaction time out handling for HHH-7910, we only tested for local (ejb) invocations but didn't test with remote invocations.

A test case is here that reproduces the error that can occur when remote EJB calls are performed with the same JTA transaction. The thrown error is "org.hibernate.HibernateException: Transaction was rolled back in a different thread!"

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

Created March 15, 2016 at 7:40 PM
Updated January 30, 2024 at 3:37 PM
Resolved January 30, 2024 at 3:37 PM

Activity

Christian BeikovJanuary 30, 2024 at 3:37 PM

I believe the original problem was fixed via https://hibernate.atlassian.net/browse/HHH-9760#icft=HHH-9760, though it's hard to track back. Anyway, closing this as out of date now.

Scott MarlowJanuary 30, 2024 at 3:33 PM

I cannot recreate this problem anymore with the original test case which I updated to Jakarta EE and also removed some non-test changes (e.g. server changes removed) originally made in the old test branch. The new test branch is https://github.com/scottmarlow/wildfly/tree/HHH-10619_txtimeoutreaper

Christian BeikovJanuary 24, 2024 at 5:34 PM

According to a discussion with Narayana folks, it should be possible to improve the handling of timeout handling by reacting to a synchronization callback: https://narayana.zulipchat.com/#narrow/stream/323715-developers/topic/Transaction.20timeout.20and.20Hibernate.20interaction

Scott MarlowMarch 15, 2016 at 9:11 PM

Some related discussion occurred on Narayana forum thread Design Discussion: Changing the reaper to use setRollbackOnly() instead of rollback() and also on Requirement for an observer SPI for tracking thread-to-transaction association changes.

In the first link on "setRollbackOnly", most of the relevant content is more toward the last few pages. The second link on "tracking thread-to-transaction association changes" is the most relevant for what we should instead be doing in Hibernate.

The idea presented in the second link, is that when the transaction manager calls Synchronization.afterCompletion(int), it is only safe to perform the desired Hibernate afterCompletion action, only if the application thread has already been disassociated from the same JTA transaction. A code example that performs this check is at https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java#L146. Note that the same class instance is implementing Synchronization + org.jboss.tm.listener.TransactionListener. The TransactionListener informs WildFly of when the application thread is associated/disassociated with the JTA transaction.

Scott MarlowMarch 15, 2016 at 8:38 PM

I think that https://github.com/scottmarlow/wildfly/commits/transactiontimeout_clientut_noejb is the test case that I created for this bug in WildFly. Let me know if you would like me to update it to work with the latest WildFly.

Flag notifications