1 Reply Latest reply on Mar 26, 2008 5:29 PM by patlv23

Unable to passivate due to ctx lock, then JBossRollbackExcep

patlv23 Mar 25, 2008 3:30 PM

Hi

I'm encountering the following with our app running on JBoss 3.2.6 on Linux. I've found what seem to be related topics on this but they said that those issues were resolved in an older JBoss release:

First I get several of each of these:
WARN [Thread-7] org.jboss.ejb.plugins.AbstractInstanceCache:tryToPassivate:163 - Unable to passivate due to ctx lock, id=com.company.ejb.entity.ChildOldEntityPK@1f61b1
WARN [Thread-7] org.jboss.ejb.plugins.AbstractInstanceCache:tryToPassivate:163 - Unable to passivate due to ctx lock, id=com.company.ejb.entity.OtherEntityPK@1f0faa
WARN [Thread-7] org.jboss.ejb.plugins.AbstractInstanceCache:tryToPassivate:163 - Unable to passivate due to ctx lock, id=com.company.ejb.entity.ChildNewEntityPK@202263
WARN [Thread-7] org.jboss.ejb.plugins.AbstractInstanceCache:tryToPassivate:163 - Unable to passivate due to ctx lock, id=com.company.ejb.entity.ParentNewEntityPK@1f61b0
WARN [Thread-7] org.jboss.ejb.plugins.AbstractInstanceCache:tryToPassivate:163 - Unable to passivate due to ctx lock, id=com.company.ejb.entity.ParentOldEntityPK@1f61a9

Then eventually, an exception is thrown:

ERROR [JMS SessionPool Worker-0] org.jboss.ejb.plugins.LogInterceptor:handleException:294 - TransactionRolledbackLocalException in method: public abstract void com.company.ejb.session.BatchSessionLocal.postBatchTxnWrapper(int,int,java.lang.String) throws com.company.common.exception.BatchException, causedBy:
org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=tjboss3//251, BranchQual=] status=STATUS_NO_TRANSACTION
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:415)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:456)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:369)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:709)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:419)
at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:83)
at $Proxy328.postCashReceiptBatchTxnWrapper(Unknown Source)
at com.company.ejb.session.BatchSessionBean.doPostBatch(BatchSessionBean.java:723)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:683)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:282)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:709)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:419)
at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:83)
at $Proxy325.doPostBatch(Unknown Source)
at com.company.ejb.mdb.BatchProcessorBean.onMessage(BatchProcessorBean.java:97)
...
...

Here is the Algorithm. It is run from a SLSB called from a MDB.

ParentOldEntity
- has many ChildOldEntity
- will have corresponding ParentNewEntity
ChildOldEntity
- has corresponding OtherEntity
- will have corresponding ChildNewEntity
ParentNewEntity
ChildNewEntity
OtherEntity

do a findBy on ParentOldEntity
Iterate ParentOldEntities
 update ParentOldEntity
 create ParentNewEntity
 do a findBy on ChildOldEntity
 Iterate ChildOldEntities
 update ChildOldEntity
 create ChildNewEntity
 collect RelatedEntity key from ChildNewEntity
 END
 Iterate collected OtherEntity keys
 do a findBy on OtherEntity with key
 update OtherEntity
 END
END

In our tests, failures seem to depend on the number of ChildOldEntity/OtherEntity.

REAL SERVER
usually 1000 ParentOldEntity
will not fail up to around 15000 ChildOldEntity/OtherEntity

VM SERVER
usually 1000 ParentOldEntity
will not fail up to around 4000 ChildOldEntity/OtherEntity

This is our BMP EntityBean configuration.

<container-configuration>
 <container-name>Standard BMP EntityBean</container-name>
 <call-logging>false</call-logging>
 <container-invoker>org.jboss.proxy.ejb.ProxyFactory</container-invoker>
 <container-interceptors>
 <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
 <interceptor metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntityInstanceInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntitySynchronizationInterceptor</interceptor>
 </container-interceptors>
 <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
 <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
 <persistence-manager>org.jboss.ejb.plugins.BMPPersistenceManager</persistence-manager>
 <transaction-manager>org.jboss.tm.TxManager</transaction-manager>
 <container-invoker-conf>
 <RMIObjectPort>4444</RMIObjectPort>
 <Optimized>True</Optimized>
 </container-invoker-conf>
 <container-cache-conf>
 <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
 <cache-policy-conf>
 <min-capacity>50</min-capacity>
 <max-capacity>25000</max-capacity>
 <overager-period>300</overager-period>
 <max-bean-age>600</max-bean-age>
 <resizer-period>400</resizer-period>
 <max-cache-miss-period>60</max-cache-miss-period>
 <min-cache-miss-period>1</min-cache-miss-period>
 <cache-load-factor>0.75</cache-load-factor>
 </cache-policy-conf>
 </container-cache-conf>
 <container-pool-conf>
 <MaximumSize>100</MaximumSize>
 <MinimumSize>10</MinimumSize>
 </container-pool-conf>
 <commit-option>C</commit-option>
 </container-configuration>

1. Re: Unable to passivate due to ctx lock, then JBossRollbackE

patlv23 Mar 26, 2008 5:29 PM (in response to patlv23)

It turns out this was a Transaction timeout issue.
The exception is thrown around 15 minutes after the process started which happens to be the TransactionTimeout setting. It's odd though that sometimes I get the above error and other times the more explicit timeout error.
Actions