Looks like a JBOSS bug

[milamipha]

I am using jboss 2.4.3. I am trying to remove EntityBeans and creating them again (I do have a reason!!!). This is all in the same session bean method. I am using caontainer transaction for the session bean. I get the following exception while doing this.
-------------------------------------------------------
[Policytopomhd2boxmapApp] Activated bean Policytopomhd2boxmapApp with id = com.r
anch.mss.objectmodel.common.Policytopomhd2boxmapPK@6cbbd313
[PolicyTopoMgrEJB] updatePolicy() has removed: topoid=53 srcmhdname=mhd1 dstmhd
name=mhd1 boxid=1

[PolicyTopoMgrEJB] updatePolicy(): inserting map: topoid=53 srcmhdname=mhd1 dst
mhdname=mhd1 boxid=1

[Policytopomhd2boxmapApp] TRANSACTION ROLLBACK EXCEPTION:INSERTING AN ALREADY EX
ISTING BEAN, ID = com.ranch.mss.objectmodel.common.Policytopomhd2boxmapPK@6cbbd3
13; nested exception is:
java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID
= com.ranch.mss.objectmodel.common.Policytopomhd2boxmapPK@6cbbd313
[Policytopomhd2boxmapApp] java.lang.IllegalStateException: INSERTING AN ALREADY
EXISTING BEAN, ID = com.ranch.mss.objectmodel.common.Policytopomhd2boxmapPK@6cbb
d313
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.AbstractInstanceCache.i
nsert(AbstractInstanceCache.java:247)
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.EntityInstanceIntercept
or.invokeHome(EntityInstanceInterceptor.java:171)
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.EntityLockInterceptor.i
nvokeHome(EntityLockInterceptor.java:108)
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
Next(TxInterceptorCMT.java:135)
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.TxInterceptorCMT.runWit
hTransactions(TxInterceptorCMT.java:307)
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
Home(TxInterceptorCMT.java:86)
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.SecurityInterceptor.inv
okeHome(SecurityInterceptor.java:103)
[Policytopomhd2boxmapApp] at org.jboss.ejb.plugins.LogInterceptor.invokeHo
me(LogInterceptor.java:106)
----------------------------------------------------
Seems to be a problem with instancepool. Somehow even after EntityBean was removed the PK of the object is still associated with the free instance ( or something like that !!!!!!!) Hence when trying to create the same bean ( same PK ) it gives this exception. Can anyone tell what is going on? TIA,
- Milind

[marc.fleury]

we do not reuse instances in jboss, so it cant be a pool thing.

[milamipha]

I check the db. It is removed successfully from db. Also I tried to do a findByPrimarykey instead of inserting. That gave the expected result the the EntityBean does not exist. But create gives me a problem.
I looked at JBOSS 2.4.3 source code. It does look like there is a InstancePool in the container.
---------------------------------------------------
if (cache.peek(key) == null)
{
cache.insert(key, ctx);
}
else
{
// Here it is a bug.
// Check for all places where insert is called, and ensure that they
cannot
// run without having acquired the cache lock via getCacheLock()
throw new IllegalStateException("INSERTING AN ALREADY EXISTING BEAN,
ID = " + key);
}
--------------------------------------------------
The code which is throwing exception is the above snippet from AbstractInstanceCache.java.
Looking at this code it is obvious that the key is not null in the cache and that is why the insert failed. I am trying to understand why the cache still holds key even when the bean was removed.
Could it be possible that this is some kind of race condition because I am removing and adding immedaiately back the bean with same key? THanks,
- Milind

[lviggiano]

I have the same problem. I believe in an JBoss BMP cache management bug.

[drcharris]

[drcharris]

(forums mucked up - all my text gone in previous message)

I get the same problem with JBoss 2.4.5RC3, using CMP beans. Steps are:

create a bean
look it up with FBPK
remove it
create another one with same id

This FAILS if the client code doing this assigns the looked up remote ref to the same remote ref from the create - it succeeds if the looked up ref is assigned to a different object. On the server this throws

javax.transaction.TransactionRolledbackException: INSERTING AN ALREADY EXISTING BEAN, ID = [.1.]; ne
sted exception is:
java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.1.]
java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.1.]
at org.jboss.ejb.plugins.AbstractInstanceCache.insert(AbstractInstanceCache.java:218)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java
:161)
at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:97)
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:142)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:347)
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:86)
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:102)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:103)
at org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:429)
at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(JRMPContainerInvoker.ja
va:389)
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)

I've checked the database and the entity is definitely not there - but the cache instance sticks around. Once this exception is thrown the cache gets cleared and I can create again. Weird.

This is not a database issue - I've tried it with Hypersonic and MS SQL Server with identical results. It's gotta be something in the cache.

[drcharris]

Forgot to say - this does NOT happen in 2.4.4