Cedric Beust wrote:
>
> > From: Jonathan Weedon [mailto:[EMAIL PROTECTED]]
>
> > 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.
>
> Actually, no.
>
> NoSuchObjectException should only be thrown if the call to the business
> method cannot be completed. In that particular case, the call will succeed
> because the business method doesn't need to load any state in order to
> complete.
>
> However, a call to a getter or a setter will result in NoSuchObjectException
> being thrown, which is the expected behavior.
Cedric,
Going through the EJB 2.0 spec, I have to agree that there is no direct
statement which your implementation violates. However, it very much
violates the spirit of the spec. Let me motivate the example a little
more.
Consider that I have a Customer Entity. The PK of the Customer Entity
happens to be the Customer's id number. However, I don't really want
to hard-code that fact into my EJB interface, so I declare the PK type
to be opaque: that is, java.lang.Object.
Now, consider I have a business method on my Customer interface, which
is used to get the customer id:
public int getCustId() throws RemoteException;
When I implement this method, I might do it as follows:
public int getCustId() {
Object pk = entityContext.getPrimaryKey();
return ((Integer) pk).intValue();
}
That is, I use the fact that I know the PK is the customer id, and use
it to get the int value.
So, here we have a perfectly valid business method that never calls a
getter or setter method. Furthermore, it does not really make sense
to put this business method on the home interface, as it really is a
proper instance-level business method.
In my opinion, the spirit of the EJB spec should not allow the first
line of getCustId() to ever execute. That is, a NoSuchObjectException
ought to have been thrown by ejbLoad before the business method is
ever invoked, in the case where the customer does not exist in the
database. But you are saying that not only can this business method
be executed, but I am guessing that the whole transaction can be
committed, even though that particular customer no longer exists
in the universe.
That's broken. I can't show you how it violates the EJB spec (the
spec does not go to that level of detail). But hopefully you can
see, from a common sense perspective, that it is broken.
[Actually, I believe the behavior is based on a much earlier version
of the EJB 2.0 specification. Early versions (ca. April 2000) of the
spec did allow for this behavior explicitly in the case of optimistic
concurrency, where the existence check was deferred to the end of the
transaction. But in the current proposed final EJB 2.0 spec, this
behavior does not seem legitimate.]
-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".
