Bugs item #529956, was opened at 2002-03-14 16:52
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=529956&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Holmes (kholmes)
Assigned to: Nobody/Anonymous (nobody)
Summary: BMP cache zombies
Initial Comment:
Windows200 server, Linux
JDK1.3.02
When using Commit
Options B or C for BMP EJBs we find that "zombie" beans remain in the
cache at the start of a new transaction when they have no underlying
database record. So it is impossible to create a new bean with the
same id as the zombie.
Finders other than the findByPrimaryKey
as defined in the ejb-jar.xml all return the correct set of ejbs, but
findByPrimaryKey still returns the zombie.
-------------------------
int teamId =
1001;
executeSQL("insert into teams (id, namestr) values ("
+teamId+", 'team1001');");
// ... get ejb remote home: teamRH
TeamRemoteIf teamRI =
teamRH.findByPrimaryKey(new
Long(teamId));
// get all the teams
Collection
teamsBeforeDelete =
teamRH.findIncludingArchived();
executeSQL("delete from teams where id = "+teamId);
Collection
teamsAfterDelete =
teamRH.findIncludingArchived();
//
this actually succeeds, so this finder is working
// as we would
expect for commit option B or C
assertTrue(teamsAfterDelete.size() ==
(teamsBeforeDelete.size() - 1) );
// now try to find it again,
shouldnt be able to
try{
teamRI =
teamRH.findByPrimaryKey(new Long(teamId));
} catch
(FinderException e){
// this is what we want to happen, but it
doesnt !
}
// this fails, teamRI is undead !!
assertNull(teamRI);
------------------------------
from our ejb-jar.xml
------------------------------
<entity>
<ejb-name>TeamBean</ejb-name>
<home>com.inceptor.entity.TeamRemoteHomeIf</home>
<remote>com.inceptor.entity.TeamRemoteIf</remote>
<local-
home>com.inceptor.entity.TeamLocalHomeIf
</local-home>
<local>com.inceptor.entity.TeamLocalIf</local>
<ejb-
class>
com.mvcsoft.pm.generated.TeamBean1016109171312
</ejb-class>
<persistence-type>Bean</persistence-type>
<prim-key-class>java.lang.Long</prim-key-class>
<reentrant>True</reentrant>
...
</entity>
<assembly-
descriptor>
...
<container-transaction>
<method>
<ejb-
name>TeamBean</ejb-name>
<method-name>*</method-
name>
</method>
<trans-attribute>Required</trans-
attribute>
</container-transaction>
...
</assembly-
descriptor>
and even though we're using MVC which doesnt
require that commit option B or C be set in the container-
configuration we set it in the jboss.xml anyway by overiding the
commit-option for "Standard BMP EntityBean" and the zombies still
persist in the cache.
If we set the max-bean-age and overager-
periods down to 1 second and sleep in between deleting the
zombiebean from sql and using findByPrimaryKey for the zombies
key, then as we expect it throws a FinderException.
Is this
still an issue in version 3 ??
regards,
Kevin Holmes
inceptor.com
----------------------------------------------------------------------
>Comment By: Kevin Holmes (kholmes)
Date: 2002-03-15 00:07
Message:
Logged In: YES
user_id=486019
The reason I reported it as a bug is from my interpretation of the EJB 2.0
spec. This from section 12.1.9
"Option B: The Container caches a
�ready� instance between transactions. In contrast to Option A, in this
option the Container does not ensure that the instance has exclusive
access to the state of the object in the persistent storage. Therefore,
the Container must synchronize the instance�s state from the persistent
storage at the beginning of the next transaction."
It seems quite
clear from this, that regardless of outside access to the persistent
store, eg via JDBC, that at the start of a new transaction an EJB should
always be resynched with the database. That is, functionally, caching
should be invisible between transactions. This is logically identical
to commit option C (which I also tried) which specifies that NO caching
should occur.
Kevin.
----------------------------------------------------------------------
Comment By: Christian Riege (lqd)
Date: 2002-03-14 18:20
Message:
Logged In: YES
user_id=176671
i've been running into something similar as the bug report
mentions but with CMP beans when using commit-option C.
haven't had the time to investigate this further though and
I can live with commit-option A for the time being.
methinks that danch is correct; the caching of primary keys
should not happen when using B/C commit option.
----------------------------------------------------------------------
Comment By: Dan Christopherson (danch)
Date: 2002-03-14 18:12
Message:
Logged In: YES
user_id=51915
I'd say we can't perform that optimization in B or C. It
breaks a lot of the scenarios where you have to use those
commit options.
----------------------------------------------------------------------
Comment By: Bill Burke (patriot1burke)
Date: 2002-03-14 17:38
Message:
Logged In: YES
user_id=176497
It seems you are trying to delete using straight JDBC and
not going through the EJB layer. This will not work ever.
You must use bean.remove().
findByPrimaryKey is optimized to look in cache first. If
it is there, it avoids the SQL query. Hmmmm....Maybe for
commit option B or C we should not do this optimization....
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=529956&group_id=22866
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
