Jonathan,
Your example could be improved by not using 'int' as a primary key type.
This is not legal in EJB. The primary key has to be a class. This caused
us a major nuisance in fact, as we had people porting code from BAS to
EAServer that wouldn't deploy as we did not accept invalid primary key
types. We have since added deployment support for these invalid types as
we didn't want to be one of the few vendors not supporting it.
"Jonathan K. Weedon" wrote:
>
> 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".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
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".
