Hey
Filip Hanik wrote:
> Michael,
> Don't worry about checking for the fields whether to read or not read the
> database.
> This should be taken care of by the container.
Sure, but sometimes the container is unnecessarily "paranoid", and does
too many calls to ejbLoad. Michaels workaround gives alot more control
over when actual db-calls are made.
> The container will call ejbLoad() when it needs the data.
No, whenever it needs to resynch, or rather, whenever it *thinks* it
needs to resynch with the db. Quite different.
> The reason your approach might fail is because the container may use the
> same entity bean (java object)
> and replace the fields with data from another row. If you don't respond
> properly to the ejbLoad method the container might think that your EJB bean
> is another data row since you didn't read.
Incorrect. Such behvaior would be delimited by ejbPassivate or ejbRemove
calls during which Michael could reset his instance so that it does
things on subsequent ejbLoad calls.
> So the container might be pooling java objects and just replacing the
> fields, so be careful.
As above, not quite true. Instances only change identity if they are
taken from the pool. For an instance to be put in the pool one of the
following must happen:
* It has just been created: setEntityContext has been called
* It has been removed: ejbRemove has been called
* It has been passivated: ejbPassivate has been called
All these methods must be used to reset the "should I do ejbLoad?" flag
to "Yes".
All clear?
/Rickard
--
Rickard �berg
@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".
