Hi!
Daniel De Luca wrote:
>
> In spec 1.1, we can read at 9.3.2 p135
>
> The implementation of each find<METHOD>(...) methods invokes a
> matching ejbFind<METHOD>(...) method.
> The implementation of the find<METHOD>(...) method must create an EJB
> object for the primary key returned from the ejbFind<METHOD>, and
> return the EJB object reference to the client.
> If the ejbFind<METHOD> method returns a collection of primary keys,
> the implementation of the find<METHOD>(...) method must create a
> collection of EJB objects for the primary keys, and return the
> collection to the client.
You gotta read between the lines though: this only means that EJBObjects
are instantiated for each entity identity. This does not imply that the
entity with the given identity is actually activated. You've only gotten
a pointer to it. Biiiiig differemce. And aboslutely necessary, see
below.
> Daniel
>
> James Cook wrote:
>
> > I understand. For CMP beans this would be a problem. The specs
> > already do
> > implement the finder methods. From what your saying, the specs also
> > force
> > the instantiation of entity beans that the finder method touches. Is
> > this
> > the case? Or is it up to the vendors what to do in these CMP-based
> > finder
> > methods?
The container should *not* instantiate the entities. Consider the
following consequence of such an implementation. If a graph of objects
is implemented by saving the primary key of the related beans in the
bean itself, and these references are looked up into real objects in
ejbActivate, then if you do findByPrimaryKey on the root object you will
get the EJBObject to it, and it will be activated. This activation in
turn starts findByPrimaryKey-calls on the related objects (as part of
the dereferencing process). The procedure is recursive so eventually all
objects that can be reached from the root are activated. Not a good
idea, right?
The only realistic way to implement this is to create the EJBObjects of
the found entities and return these, deferring the actual activation to
the time of the first call.
A naive implementation of this might have some performance problems,
especially on high-volume systems (lots of objects in the database). If
a finder method returns 1000 objects, which are then called in turn, it
will result in 1001 database calls (each entity is activated
separately). A optimized container would cache the results of the finder
method and reuse this data instead of doing those 1000 database calls.
Another aspect is that if those 1000 objects were already activated
there is no penalty at all. All EJBObjects and entities are activated
and waiting to be used. Just return them to the user and be happy. Which
leads to an important optimization note: if your container supports
setting the size of the active entity pool and the max. nr of active
entities is known (lets say 100 objects), then you should set the size
to this number. Eventually this will lead to that all entities are
activated and any calls to them will not cause the database to be
accessed.
Hope this helped some..
/Rickard
--
Rickard �berg
Computer Science student@LiTH
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
