Transaction Rolled back due to timeout

[glassfishrobot]

After upgrade from GF 4.1 to Glassfish 4.1.1, I get timed out transactions, with a warning in the log: Warning: EJB5123:Rolling back timed out transaction [JavaEETransactionImpl: txId=51 nonXAResource=9 jtsTx=null localTxStatus=1 syncs=[com.sun.ejb.containers.SimpleEjbResourceHandlerImpl@2df56bef, com.sun.ejb.containers.ContainerSynchronization@3f02d7bb, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@5fd05f0e, org.eclipse.persistence.transaction.JTASynchronizationListener@6a5a3c2b, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@6cf6889c, org.eclipse.persistence.transaction.JTASynchronizationListener@456035b6]] for [PlaineService]

The method triggering this rollback imports a fair amount of data and regularly flushes the persistence context. Yet, once completed after several minutes, the warning and rollback occur.

The presence of @Asynchronous or @TransactionAttribute annotations to the method does not seem to have any impact on this issue.

Using GF 4.1, the method worked correctly.

Affected Versions

[4.1.1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/21495
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @naman223
• Original Issue Closed By:@amykang2020

[glassfishrobot]

@glassfishrobot Commented napu said: I can confirm the same issue.

[glassfishrobot]

@glassfishrobot Commented iordannalbantov said: We have it too. The consequent problem is that our timers are expunged afterwards which makes it critical for us. Downgrade is not an option because we will hit other critical bugs which were already fixed. Unfortunately setting Maximum Redeliveries of the EJB Timer Service to a higher number doesn't work neither.

[glassfishrobot]

@glassfishrobot Commented douglasjunior said: I also have a method that persists much data.

It displays Warn, but the data is successfully persisted. Exception is not thrown. This Warn has caused problems for you?

I can ignore it?

[glassfishrobot]

@glassfishrobot Commented fgonzales said: We are running into the same issue. I also verified that Glassfish 4.1 does not have this problem. It looks specific to 4.1.1.

[glassfishrobot]

@glassfishrobot Commented lprimak said: I suggest you open a Payara issue for this. It would help also if you have a ready reproducer application available.

[glassfishrobot]

@glassfishrobot Commented rgrashel said: Is there any movement on this issue? if can be used to extend the transaction timeout of an EJB timer, can someone please post an example of what the glassfish-ejb-jar.xml file looks like? I have tried variations and simply cannot get it to work. For long-running jobs, this is absolutely a critical issue if you cannot use an EJB Timer with a long-running job.

[glassfishrobot]

@glassfishrobot Commented lprimak said: Both GlassFish and Payara are actually functioning property in this instance. The solution for this is either to extend the tx timeout via cmt-timeout-in-seconds or via domain configuration.

Or break up the service into multiple EJBs, base with no tx that calls others that manipulate the database.

[glassfishrobot]

@glassfishrobot Commented fgonzales said: In EJBContainerTransactionManager, cmtTimeoutInSeconds is hardcoded to 120 seconds. This was a change made in 4.1.1. This hard-coded value cannot be over-ridden via the domain configuration. It can only be overridden individually for each EJB, which is not very practical if you have a lot of them.

[glassfishrobot]

@glassfishrobot Commented lprimak said: I'm pretty sure I configured 30 minutes and it works in Payara with the domain configuration, it I'll re-test

[glassfishrobot]

@glassfishrobot Commented lprimak said: I have just re-tested Tx timeouts with the latest Payara, and they are confirmed to work as designed. I changed Transaction Service -> Transaction Timeout from non-zero to 30 seconds, and it times out after 30 seconds, and if it's at zero, it doesn't time out (unless you count esoteric stuff like CORBA which times out after 30 minutes)

[glassfishrobot]

@glassfishrobot Commented fgonzales said: So this is already fixed in Payara? In Glassfish 4.1.1 this issue definitely exists.

[glassfishrobot]

@glassfishrobot Commented rgrashel said: If this works in Payara, great. But this defect is about upstream Glassfish. My question to the Glassfish team – when is a fix for this going to be issued? It is not reasonable to ask users to declare methods as TransactionAttribute.NOT_SUPPORTED because they have long-running methods. Nor is it reasonable to ask users to break apart EJBs in strange ways simply to isolate intentionally long-running EJB methods.

[glassfishrobot]

@glassfishrobot Commented dirkroets said: We've ran into this issue on GF 4.1.1 as well. I've looked through the source code and this bug was introduced with the code changes that fixed #21175

Setting the default TX timeout back to 0 (disabled) is trivial, so we've compiled a new version of /glassfish/modules/ejb-container.jar that fixes the problem for us.

[glassfishrobot]

@glassfishrobot Commented Was assigned to srini.gf

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-21495

[glassfishrobot]

@glassfishrobot Commented Reported by cghislai

[glassfishrobot]

@amykang2020 Commented @dirkroets's comment

We've ran into this issue on GF 4.1.1 as well. I've looked through the source code and this bug was introduced with the code changes that fixed #21175

#21175 is a change in transaction service, transfer jts component to have a look.

[glassfishrobot]

@amykang2020 Commented

• From @naman223: I can see the option (Transaction Service -> Transaction Timeout) under the latest GlassFish. And if it's at zero, it doesn't time out.

• Additionally the EJB descriptor attribute cmt-timeout-in-seconds can be used to override the default 120 seconds timeout value of cmtTimeoutInSeconds in EJBContainerTransactionManager

[zistrong]

this bug still haven't fixed in glassfish 5 & 6;