On Fri, 2003-11-07 at 20:29, Fletcher, Peter S wrote:
> Including a finder definition in an EJB such as:
>
>
> public abstract DataObjPK ejbFindByPrimaryKey (DataObjPK pk);
>
>
> generates a call in a generated BMP such as
>
> public DataObjPK ejbFindByPrimaryKey(DataObjPK pk)
> {
> return getDao().findByPrimaryKey(pk);
> }
>
>
>
> Question: how can the DAOImpl.findByPrimary key method populate the
> ejb's attributes? It does not have a reference to the ejb. Other
> calls to DAO methods (load, store, create) all pass a reference to the
> ejb. It would be nice to have that reference in the finder methods,
> unless I'm misunderstanding????
You're misunderstanding. Finders aren't meant to populate the fields;
that's ejbLoad's job. Finders just return the PK (or collection of
PKs), and the container translates these into a bean reference (or
collection of references) which get returned to the caller. If you then
call any methods on the returned interface(s), the container will ensure
ejbLoad gets called on the bean instance before making the corresponding
method call.
> If the method is not declared abstract, then the BMP has a call to
> super, then it calls the DAO. If that strategy is taken, then the
> super can populate its attributes, but then it has to implement data
> access, which is supposed to be encapsulated in the DAO. Also, then
> what is the point of the call to DAOImpl.find if the call to super has
> already done the work, other than just to return the PK?
The only reason for the super call is if you want to e.g. write a debug
log message when the finder is called (okay, perhaps not the only
reason, but it's the most likely one I can think of). You're not
supposed to be storing any state in the finders (*). Indeed, if I
recall correctly, there's no guarantee that the bean instance used to
execute the finder method will necessarily be the same one that
subsequently gets ejbLoad'ed if you do call any methods on it (the
container just grabs one from its instance pool in each case), so
there's no guarantee the values you'd stored would still be there
anyway...
Andrew.
(*) though some app servers' CMP implementations can optionally cache
the state, ready for the load method to use, as an optimisation to avoid
the "N+1 select" problem. You could perhaps do likewise in your DAO
implementation class, if you're having performance issues.
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
