removing bean lock and it has tx set

[pike]

For first - I've read discussion about this and it's not helpful for me. I'm sure I have right implementation of equals and hashCode in PK class and this one is serialized without troubles.

I use BMP entity bean on JBoss 3.0.4 and when I call any find method (for example findByPrimaryKey) I get error "removing ...". When I deploy this application on OC4J 9.0.3 all work without problem.

Truncated print-out:

START METHOD setEntityContext
START METHOD ejbFindByPrimaryKey
4-times:
START METHOD hashCode
START METHOD setEntityContext
START METHOD ejbActivate
3-times:
START METHOD hashCode
START METHOD ejbLoad
3-times:
START METHOD hashCode
START METHOD getCatalogueObj
--- CatalogueObj: cz.mercury.register.datacat.ejb.impl.CatalogueObj@13c366 ---
catNo = 255
id = 1
no = 1
-------------------------------
// just here OC4j end work. Why JBoss continue?
START METHOD hashCode
START METHOD equals
START METHOD hashCode
--- PK original: cz.mercury.register.datacat.ejb.CataloguePK@5e90f ---
START METHOD hashCode
--- PK strange: cz.mercury.register.datacat.ejb.CataloguePK@5e90f ---
START METHOD hashCode

5-times this block with the same instance of PK:
START METHOD hashCode
START METHOD equals
START METHOD hashCode
--- PK original: cz.mercury.register.datacat.ejb.CataloguePK@809ce ---
START METHOD hashCode
--- PK strange: cz.mercury.register.datacat.ejb.CataloguePK@809ce ---

ERROR [LogInterceptor] RuntimeException:
java.lang.IllegalStateException: removing bean lock and it has tx set!CatalogueEJB cz.mercury.register.datacat.ejb.Catal
oguePK@5e90f
at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.removeRef(QueuedPessimisticEJBLock.java:427)
at org.jboss.ejb.BeanLockManager.removeLockRef(BeanLockManager.java:107)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:124)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204)
at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493)
at org.jboss.ejb.Container.invoke(Container.java:712)
at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382)
at java.lang.reflect.Method.invoke(Native Method)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
at sun.rmi.transport.Transport$1.run(Transport.java:147)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:143)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:479)

CatalogueObj is serialized class which holds attributs of Catalogue and CatalogueEjb hold instance of CatalogueObj. CatalogueObj is serialized correctly too.

Have anybody idea how to solve this problem?

[adrian.brock]

Show some code and deployment descriptors.
Your own personnel logging isn't much use without it.

A simple testcase that reproduces the problem is
the best way to get this looked at quickly.

It is likely OC4J wraps your primary key to
prevent errors, jboss2.x did the same, but this
wrapping was removed because people who implemented
primary keys correctly payed a performance penalty.

Regards,
Adrian

[pike]

Ok, so I'll send you some files. I truncated some codes and deleted unusable method in EJB for this problem ...