Chip Wilson wrote:
> I can tell you from personal experience that this behavior varies from one
> vendor to another. I suggest you contact the vendor of your container for
> specific options to control this behavior.
>
> > -----Original Message-----
> > From: Mark Cassidy [SMTP:[EMAIL PROTECTED]]
> > Sent: Sunday, July 11, 1999 9:05 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: EJBObject
> >
> > Perhaps this situation explains one of my questions
> > about findByPrimaryKey -- the fact that in my testing
> > findByPrimaryKey seems to always call the bean's find
> > method even if it has just been created and is there
> > in the container's cache. If it always calls the find
> > routine, then it is reassured that the entity bean
> > hasn't been removed via a backdoor. (Going back to
> > the persistent store each time for a refind/reload
> > seems like overkill and should not be the default
> > behavior, IMHO. If anyone knows of a way to switch
> > that off or what I'm doing wrong, please let me know.)
>From the point of view of the 1.0 specification, at least, this is necessary
behavior, since the find message is not sent to an active bean at all, but to
one which is still in the pool, and so has no defined internal state. Now, of
course, since the bean developer writes the find method (in the bean-managed
case), he or she has the option to short-circuit going to the persistent store
for data. Such code would necessarily be container-dependent, of course, since
there aren't any standard APIs (at least in the context of EJB) for accessing a
local cache.
<VENDOR>
>From the point of view of a container implementor. at GemStone we've been at
some pains to ensure that all find() methods are called in the context
described by the spec. In particular, the bean instance used for the find
method has been sent setEntityContext(), but not ejbCreate() or ejbLoad() or
ejbActivate(). We have *not* provided any programmatic or
declarative-deployment mechanism for modifying the behavior of find methods
from the container. What we have provided is a set of APIs for either
controlling a local persistent cache in front of a separate persistent store,
or creating the entire persistent store local to the bean, without requiring a
separate database tier.
</VENDOR>
Bruce Cohen [EMAIL PROTECTED]
GemStone Systems, Inc. 20575 NW von Neumann Drive
Beaverton, OR, 97006
phone: 503.533.3602 fax: 503.629.8556
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
