java - ConcurrentModificationException thrown by GlassFish 3.1.2.2 on commit of XA transaction -
we have singleton ejb bean deployed in glassfish 3.1.2.2 server following annotations:
@concurrencymanagement(concurrencymanagementtype.bean) @singleton @startup @local(xxx.class) @transactionattribute(transactionattributetype.never)
the bean injected servlet calls several methods on it. randomly, server.log shows there concurrentmodificationexception thrown random methods of bean on commit of xa transaction.
javax.transaction.xa.xaexception: java.util.concurrentmodificationexception @ com.sun.enterprise.resource.connectorxaresource.handleresourceexception(connectorxaresource.java:115) @ com.sun.enterprise.resource.connectorxaresource.resetassociation(connectorxaresource.java:287) @ com.sun.enterprise.resource.connectorxaresource.commit(connectorxaresource.java:128) @ com.sun.enterprise.transaction.javaeetransactionimpl.commit(javaeetransactionimpl.java:501) @ com.sun.enterprise.transaction.javaeetransactionmanagersimplified.commit(javaeetransactionmanagersimplified.java:855) @ com.sun.ejb.containers.basecontainer.completenewtx(basecontainer.java:5136) @ com.sun.ejb.containers.basecontainer.postinvoketx(basecontainer.java:4901) @ com.sun.ejb.containers.basecontainer.postinvoke(basecontainer.java:2045) @ com.sun.ejb.containers.basecontainer.postinvoke(basecontainer.java:1994) @ com.sun.ejb.containers.ejblocalobjectinvocationhandler.invoke(ejblocalobjectinvocationhandler.java:222) @ com.sun.ejb.containers.ejblocalobjectinvocationhandlerdelegate.invoke(ejblocalobjectinvocationhandlerdelegate.java:89) @ com.sun.proxy.$proxy258.gethostmonitorrecord(unknown source) @ ...xprotocolhostservletbase.handledocument(xprotocolhostservletbase.java:174) @ ...transactionhandlerservletbase.dopost(transactionhandlerservletbase.java:44) @ javax.servlet.http.httpservlet.service(httpservlet.java:688) @ javax.servlet.http.httpservlet.service(httpservlet.java:770) @ org.apache.catalina.core.standardwrapper.service(standardwrapper.java:1550) @ org.apache.catalina.core.standardwrappervalve.invoke(standardwrappervalve.java:281) @ org.apache.catalina.core.standardcontextvalve.invoke(standardcontextvalve.java:175) @ org.apache.catalina.core.standardpipeline.doinvoke(standardpipeline.java:655) @ org.apache.catalina.core.standardpipeline.invoke(standardpipeline.java:595) @ org.apache.catalina.core.standardhostvalve.invoke(standardhostvalve.java:161) @ org.apache.catalina.connector.coyoteadapter.doservice(coyoteadapter.java:331) @ org.apache.catalina.connector.coyoteadapter.service(coyoteadapter.java:231) @ com.sun.enterprise.v3.services.impl.containermapper$adaptercallable.call(containermapper.java:317) @ com.sun.enterprise.v3.services.impl.containermapper.service(containermapper.java:195) @ com.sun.grizzly.http.processortask.invokeadapter(processortask.java:860) @ com.sun.grizzly.http.processortask.doprocess(processortask.java:757) @ com.sun.grizzly.http.processortask.process(processortask.java:1056) @ com.sun.grizzly.http.defaultprotocolfilter.execute(defaultprotocolfilter.java:229) @ com.sun.grizzly.defaultprotocolchain.executeprotocolfilter(defaultprotocolchain.java:137) @ com.sun.grizzly.defaultprotocolchain.execute(defaultprotocolchain.java:104) @ com.sun.grizzly.defaultprotocolchain.execute(defaultprotocolchain.java:90) @ com.sun.grizzly.http.httpprotocolchain.execute(httpprotocolchain.java:79) @ com.sun.grizzly.protocolchaincontexttask.docall(protocolchaincontexttask.java:54) @ com.sun.grizzly.selectionkeycontexttask.call(selectionkeycontexttask.java:59) @ com.sun.grizzly.contexttask.run(contexttask.java:71) @ com.sun.grizzly.util.abstractthreadpool$worker.dowork(abstractthreadpool.java:532) @ com.sun.grizzly.util.abstractthreadpool$worker.run(abstractthreadpool.java:513) @ java.lang.thread.run(thread.java:724)
apparently, method calls attached container managed transaction, though bean annotated transactionattributetype.never. question why bean still transactional , may causing random occurrence of exception.
i have debugged glassfish sources , found out cause why methods of our bean still transactional.
the reason our bean has superclass didn't have @transactionattribute annotation, therefore methods not overridden in our bean had default transactionattributetype.required.
how container treats transaction related annotations in case of inheritance explain e. g. in answer https://stackoverflow.com/a/5542890/5048604
Comments
Post a Comment