ConcurrentModificationException брошенной GlassFish 3.1.2.2 на совершение сделки по XA

Мы боб Singleton EJB развернут в 3.1.2.2 сервере GlassFish со следующими примечаниями:ConcurrentModificationException брошенной GlassFish 3.1.2.2 на совершение сделки по XA

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

боб впрыскивается в сервлет, который вызывает несколько методы на нем. Случайно, server.log показывает, что существует ConcurrentModificationException, созданное случайными методами компонента для фиксации транзакции XA.

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)

Видимо, вызовы метода прикреплены к контейнеру удалось сделки, даже несмотря на то, боб с аннотацией TransactionAttributeType.NEVER. Мой вопрос в том, почему bean все еще транзакционный и что может вызвать случайное появление этого исключения.

источник

2015-06-25 Pavel Šindelář

Остальная трассировка стека была бы полезна. Является ли метод getHostMonitorRecord' для компонента @Singleton? –

Да, getHostMonitorRecord - это метод компонента Singleton. Я добавил полную трассировку стека. –

Возможно ли, что 'getHostMonitorRecord' вызвал то, что начинает транзакцию? –

Я отлаживал источники GlassFish и выяснял причину, почему некоторые методы нашего компонента по-прежнему были транзакционными.

Причина в том, что у нашего компонента есть суперкласс, у которого не было аннотации @TransactionAttribute, поэтому методы, которые не были переопределены в нашем компоненте, имели значение TransactionAttributeType.REQUIRED по умолчанию.

Как контейнер рассматривает связанные с транзакцией аннотации в случае наследования, объясняет e. г. в этом ответе https://stackoverflow.com/a/5542890/5048604

источник

2015-06-30 16:12:24

ConcurrentModificationException брошенной GlassFish 3.1.2.2 на совершение сделки по XA

ответ

Смежные вопросы