Bugs item #529956, was opened at 2002-03-14 10: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: Dan Christopherson (danch)
Date: 2002-03-14 12: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 11: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
