ConcurrentModificationException thrown by GlassFish 3.1.2.2 on commit of XA transaction

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.

The rest of the stack trace would be useful. Is `getHostMonitorRecord` a method on the @Singleton bean? — Steve C, Jun 25 '15 at 12:52
Yes, getHostMonitorRecord is a method of the Singleton bean. I have added complete stack trace. — Pavel Šindelář, Jun 25 '15 at 13:04
Is it possible that `getHostMonitorRecord` has called something that starts a transaction? — Steve C, Jun 25 '15 at 13:11
Actually, it is simple getter with one line calling threadLocalVariable.get(). — Pavel Šindelář, Jun 25 '15 at 13:22
It may be a bug in Glassfish. Or perhaps your `ConcurrencyManagementType.BEAN` is responsible — Steve C, Jun 25 '15 at 13:25
ConcurrencyManagementType.BEAN just tells the container not to synchronize bean methods, I don't think it has anything to do with the transaction management. — Pavel Šindelář, Jun 25 '15 at 13:30

score 0 · Answer 1 · edited May 23 '17 at 12:22

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 e. g. in this answer https://stackoverflow.com/a/5542890/5048604

ConcurrentModificationException thrown by GlassFish 3.1.2.2 on commit of XA transaction

1 Answers1