The
optimization would still work within the same transaction.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vincent Harcq
Sent: Tuesday, June 19, 2001 12:00 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Is findByPrimaryKey optimized enough in JAWS/CMP, even BMP?Hi,I am not expert at all in all these but,...In commit-option C, a EntityInstanceCache may exist and then the row removed by an external system, so you have to read from db to be sure the entity still exists.Vincent.-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Bill Burke
Envoyé : mardi 19 juin 2001 16:58
À : Jboss-Development@Lists. Sourceforge. Net
Objet : [JBoss-dev] Is findByPrimaryKey optimized enough in JAWS/CMP, even BMP?The reason I ask is that it seems all finders go straight to the Persistence manager with no optimizations in front of it. Couldn't "findByPrimaryKey" look in the EntityInstanceCache and avoid a DB, "does exist", call? Is this as easy as modifying org.jboss.ejb.EntityContainer.find(...) ?? You're safe if "findByPrimaryKey" has been overrided by the Bean developer because org.jboss.jeb.EntityContainer.setupHomeMapping will not map the finder to EntityContainer.find, but rather to the Bean class. At first glance, I can't find words stating that this optimization is illegal, although the Object Interaction Diagram does show a call to the database for ejbFind. Comments?Thanks,Bill
