Cedric Beust wrote:
>
> > From: Jonathan Weedon [mailto:[EMAIL PROTECTED]]
>
> > Consider the user has a handle to an Entity bean. Now, consider
> > that there exists a method on this Entity bean which is executed
> > without ever calling any getter or setter methods (arguably a
> > stupid method to put on an Entity bean, but not illegal). Now,
> > consider that someone snuck into the database and deleted the
> > given Entity record, unbeknownst to the container (maybe this
> > was done in a concurrent call to another container). In such a
> > case (with a noop ejbLoad) a call to this method (which omits
> > getter/setters) will not detect that the entity does not actually
> > exist in the database. That is, the call will not result in a
> > NoSuchObject exception, although it should.
>
> If the method executed on the Entity bean never calls any getter method,
> then it doesn't need the state of the bean (and I would argue that this
> method should be a home method, but that's a separate issue).
>
> And in anticipation to your next remark ;-) : we automatically resort to
> Commit Option C when <db-is-shared> is set to True.
Cedric,
I fully agree that:
1) "it doesn't need the state of the bean", and
2) "this method should be a home method".
However, you still need to verify the existence of the record in the
database, and therefore ejbLoad cannot be a noop. It does not matter
whether you use commit option B or C, you need to go to the database,
in order to know whether to throw a NoSuchObjectException, as per the
EJB 2.0 (and 1.1) specification. That is, lazy loading cannot correctly
be taken to quite the extreme as to never go to the database for a
use case.
-jkw
===========================================================================
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".
