EJBTransactionRolledbackException occasionally occurs on @Asynchronous Function

Question

I am using Java 1.6.0_23 and Glassfish 3.1.1. I have two Singleton EJBs. One is using the TimerService to fire the @Timeout function. During the @Timeout, an @Asynchronous function in called in the other Singleton EJB. It works 95% of the time without any errors. But the other 5% of the time when the @Asynchronous function is called, I get the following error with no evidence that it even started the @Asynchronous function. No other error details are logged.

Any ideas?

PS: I tried increasing the max number of EJBs in Glassfish from 32 to 64. No change.

java.util.concurrent.ExecutionException: javax.ejb.EJBTransactionRolledbackException
        at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:132) ~[ejb-container.jar:3.1.1]
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[na:1.6.0_23]
        at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[na:1.6.0_23]
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_23]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_23]
        at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_23]
Caused by: javax.ejb.EJBTransactionRolledbackException: null
        at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2305) ~[ejb-container.jar:3.1.1]
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2088) ~[ejb-container.jar:3.1.1]
        at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:114) ~[ejb-container.jar:3.1.1]
        ... 5 common frames omitted
Caused by: javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
        at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4699) ~[ejb-container.jar:3.1.1]
        at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4577) ~[ejb-container.jar:3.1.1]
        at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1910) ~[ejb-container.jar:3.1.1]
        at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:99) ~[ejb-container.jar:3.1.1]
        ... 5 common frames omitted

Solution 1

You'll have to look for other errors that happened before this one (maybe swallowed exceptions, since you said there are no other errors). EJBTransactionRolledbackException occurs if the current trx has been marked for a rollback, and you're still doing stuff on the DB.

Solution 2

Happened to me as well. Seems the problem is not a coding problem, but server resources.

I increased the http thread pool size It was 5 max for me and I changed it to 10

Seems to resolved the problem.

Also some notes on this error here: http://pcjuzeren.blogspot.co.il/2008/12/clients-transaction-aborted.html

Comments

[mauman]

I double checked. I could find no other exceptions in my logs. Every catch() has a logging statement too. Also, this EJBTransactionRolledbackException exception appears to occur immediately (4 milliseconds tops) upon calling the @Asynchronous function in the 2nd EJB, and not waiting for any database connection.

[alvi]

is it possible you're holding a reference to the entitymanager? it's important to have it container managed by injection.

[mauman]

I am indeed depending on the injection: PersistenceContext(unitName = "myPersistenceUnit") private EntityManager em; ... and never using a factory to create the entitymanager, or anything like that.

[alvi]

sorry, can't suggest anything more with the information provided. I've seen this exception under such circumstances, e.g. when an em was being reused in a non-jee conforming way. You might simply be dealing with a container bug. :(

[mauman]

Good point. I'll double check the Glassfish issues. It would not be the first time I found a defect in Glassfish. Thanks for your help.

[ymajoros]

Quite sure there is a server defect here: even if it's probably caused by something else, an erroneous transaction somehow is linked to some http thread. Double check your logs: it probably always happen on the same http worker thread. If you resize the http thread pool, it will be rebuilt and the problem will be gone (until it comes back). Saw this in a couple of situations (but there was always a previous cause.