Evan, It just struck me, how would a bean developer handle this problem? I mean from the perpective of someone who develops business logic.
I would probably leave the deferring of the create() as such - iff the likelihood of exceptions being thrown is minimal. My first reaction to this was to turn off deferring the create() altogether and this I suppose would be reaction of most other developers out there as well. From a (Container) performance point of view, I agree that deferring database calls is a valid optimization. Also, it allows the Container to reorder updates to the database (for eg: updates can be reordered so as to maintain referential integrity). I do hope some developers respond with their thoughts ... -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Evan Ireland > Sent: Friday, January 25, 2002 9:40 PM > To: [EMAIL PROTECTED] > Subject: Re: deferring database calls > > > Krishnan, > > I would suggest that deferred creation is a valid optimization, > but not a valid default behaviour (imagine the scenario where > a session bean tries to find the new entity before the ejbStore > has been called). > > Krishnan Subramanian wrote: > > > Hi all, > > > > I've been struggling to understand the effect of Containers > > deferring database calls. > > > > I'll take the relatively simple example of an ejbCreate() > > being deferred. That is, a client starts a transaction, > > calls the create() on the home interface of an entity bean > > and the Container defers the actual creation (SQL 'INSERT') > > until the end of the transaction. > > > > Note: Let us assume the case when there are no other transactions > > (or finders etc) that need to work with that entity instance. > > (If they did, then the EJB 2.0 spec dictates that the > > Container would have to update the database, Collection > > returned by finders etc accordingly or something similar). > > > > Since the actual update to the database is deferred, the > > create() would actually seem to succeed - (eg: even if I > > violate some foreign key constraint - not the primary key > > though). This would imply that an exception would not be > > thrown at this point, but rather it would be thrown when > > the Container tries to update the database at the end of > > the transaction. > > > > If the ejbCreate was not deferred, then this method was fail > > resulting in an AppException (as per section 18.3 in the > > EJB 2.0 spec). That is, the client would receive a CreateException. > > > > If the ejbCreate was indeed deferred, this would lead to a > > failure in the Container callback method - ejbStore(). As > > per secion 18.3.3, this would result in the transaction > > being marked for rollback and the remote client receiving > > a java.rmi.RemoteException. > > > > This implies that my error handling code at the client > > would possibly break. (It receives a RemoteException, > > when in all probability, it should receive an AppException > > or a user defined exception). > > > > Comments? If I have gotten things wrong, an explanation > > would be much appreciated. > > > > -krish > > > > PS: Of course deferring can turned off by a flag or some > > other means, in which case everything would work as expected. > > But that is not the case we are discussing here. > > > > =========================================================================== > > 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". > > =========================================================================== 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".
