GlassFish 3.1.2.2在提交XA事务时抛出ConcurrentModificationException

Question

We have a Singleton EJB bean deployed in GlassFish 3.1.2.2 server with the following annotations:

@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Singleton
@Startup
@Local(XXX.class)
@TransactionAttribute(TransactionAttributeType.NEVER)

The bean is injected into a servlet which calls several methods on it. Randomly, the server.log shows that there are ConcurrentModificationException thrown by random methods of the bean on commit of XA transaction.

javax.transaction.xa.XAException: java.util.ConcurrentModificationException
    at com.sun.enterprise.resource.ConnectorXAResource.handleResourceException(ConnectorXAResource.java:115)
    at com.sun.enterprise.resource.ConnectorXAResource.resetAssociation(ConnectorXAResource.java:287)
    at com.sun.enterprise.resource.ConnectorXAResource.commit(ConnectorXAResource.java:128)
    at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:501)
    at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:855)
    at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5136)
    at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4901)
    at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2045)
    at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994)
    at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
    at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
    at com.sun.proxy.$Proxy258.getHostMonitorRecord(Unknown Source)
    at ...XProtocolHostServletBase.handleDocument(XProtocolHostServletBase.java:174)
    at ...TransactionHandlerServletBase.doPost(TransactionHandlerServletBase.java:44)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
    at java.lang.Thread.run(Thread.java:724)

Apparently, the method calls are attached to the container managed transaction, even though the bean is annotated with TransactionAttributeType.NEVER. My question is why is the bean still transactional and what may be causing the random occurrence of this exception.

Answer 1

I have debugged the GlassFish sources and found out the cause why some methods of our bean were still transactional.

The reason is that our bean has a superclass which didn't have the @TransactionAttribute annotation, therefore methods that were not overridden in our bean had the default TransactionAttributeType.REQUIRED.

How the container treats the transaction related annotations in case of inheritance is explain eg in this answer https://stackoverflow.com/a/5542890/5048604