Skip to main content

Client's transaction aborted

By tvik
I've met the above error message using a Wicket 1.2 / EJB3 intranet application under Glassfish v2.
Here is the more particular head of the stack trace:

javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:3394)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:3274)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1244)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)

This exception raised on the integration server sometimes, randomly, for simple page fetch operations. After pressing reload on the browser, the operation was usually successful. I couldn't reproduce the failure on the local machine where I regularly restart the app server and have run some tiny applications only beside the subject one.

After some hours code bugging I'd found a forum message which gave me an idea to play some rounds with the Glassfish's HTTP Service configuration. Maybe not my EJB logic is buggy or misconfigured but the client web application causes the error somehow. Unfortunately I couldn't quarry anything regarding this from the default server logs.

Finally I tried the following on the Glassfish admin console which solved the problem as a symptomatic treatment:
Configuration > HTTP Service > RequestProcessing > Thread Count (set a higher value, the default is 5. 10 is worked for me.)

It seems to be working now.
Labels:

Comments

Felipe Roos said…
Hey, did you find anything else related to his issue? I'm having the same, following your suggestion it apparently worked.
December 13, 2011 at 12:11 PM
tvik said…
Hi, I didn't do more investigation on this.
December 13, 2011 at 1:03 PM
Daniel said…
Great! Solved the problem for me too. Thanks!
June 13, 2012 at 11:25 AM
Post a Comment

Popular posts from this blog

jxl.log

By tvik
In an intranet production environment we have running a Glassfish v2 appserver with several J2EE applications which all use JexcelApi , a.k.a JXL, which is an open source library for accessing, generating or manipulating Microsoft Excel documents. We use version 2.6.3 of JXL because it's the recent one in the Maven repository which we use, however, at the official JXL site there are newer versions. Additionally we have log4j and Java Commons Logging (JCL), ignoring Glassfish's JSR-47 Java Util Logging (JUL) facility. Application #1 uses purely log4j and gets its log4j.xml config from a custom location. Application #2 runs Java Commons Logging with no explicite configuration file given, so JCL uses the default JUL facility of the appserver. Application #1 had been running for a long time without problems but when we installed #2 we realized that a jxl.log file had been created in the glassfish/domain/domain1/config directory and it's rapidly growing. As it happens, we ...
3 comments
Read more

Setting up EJB3 default interceptor

By tvik
It wasn't easy to find out how to configure a default interceptor in EJB3 environment. It's okay to make this snippet into the ejb-jar.xml: <assembly-descriptor> <interceptor-binding> <ejb-name>*</ejb-name> <interceptor-class>pkg.IC</interceptor-class> </interceptor-binding> </assembly-descriptor> Maybe everybody forget to mention maybe it's a Glassfish V2 trick that I get this error message during deployment: Interceptor binding contains an interceptor class name = pkg.IC that is not defined as an interceptor ...unless I register the interceptor class itself too with this: <interceptors> <interceptor> <interceptor-class>pkg.IC</interceptor-class> <around-invoke> <method-name>call</method-name> </around-invoke> </interceptor> </interceptors> <interceptors> and <as...
3 comments
Read more