Isn't that B (I thought it was C that uncached and sent the impl back to
the pool)
Vincent Harcq wrote:
> 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
>
>
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
