Johan Eltes wrote: > Whatabout updates? > > - There is no "update" method in the client api (unlike home create, that > mirrors "insert"). > - RI SQL exceptions can not be processed by business logic > - The finder problem scenario for deferred create is always there for > updates. Does the spec (2.0) require that the container run the EJB QL > queries also on the entity cache, before returning the result to the caller?
Either that or the updates should not be deferred (by default) either. If the implementation can detect that it is safe to defer the updates by default, then I suppose it is free to do so. However it is difficult to tell what session beans are doing in any automated way. Thus in many cases it can be argued that deferred insert/update is illegal as a default behaviour. > Otherwise there the result could be inconsistent with the state in the > cache? > > /Johan > > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Evan Ireland > Sent: den 26 januari 2002 00:26 > To: [EMAIL PROTECTED] > Subject: Re: deferring database calls > > Krishnan, > > I would suggest that your R&D folks disable deferred inserts > by default. This really is an optimization that is not strictly > valid according to the EJB spec. (It is of course valid if the > deployer specifies that deferred inserts are acceptable). > > Here is an argument why deferred inserts are not valid by default: > > (1) ejbCreate returns. > > (2) ejbPostCreate calls a session bean which queries the underlying > DBMS table and can't find the row which corresponds to the newly > 'created' entity. > > (3) At some later time, ejbStore is called and does the insert. > Too late now, as the session bean didn't work. > > Hopefully one day we'll have a J2EE CTS test for entity beans that > verifies the default behaviour of entity bean lifecycle isn't > 'cheating'. > > Krishnan Subramanian wrote: > > >>Evan, >> >>Thanks for the response - actually, I got the following case from >>a pretty realistic situation. Let's assume the case as follows: >> >>Remote client <--> Session Bean <--> local Entity bean >>(the popular session facade pattern). >> >>Now, the session bean and the entity bean(s) have the transaction >>attributes "Required". This I assume is a normal scenario. Of course >>there might be cases when these attributes are domain specific (e.g: >>RequiresNew etc), but we are not considering these. >> >>Session bean has some method: doSomething() that does the following: >> >>public void doSomething throws SomeUserException { >> try { >> // lookup/use local home of entity bean >> // call create() on above reference >> // do other stuff (say on other entity beans) >> } >> catch (Exception e) { >> // take appropriate action (whatever might be the case) >> // throw SomeUserException >> // but never get here in this block if the create is deferred. >> // Of course - if turned off then the exception handling works >> // as expected. >> } >>} >> >>The above is a fairly common piece of code - so if the create was >>deferred, the entire exception handling mechanism (in my session >>bean) breaks down. >> >>Talking to R&D, they suggest that the above can be avoided by having >>the entity bean's create() have transaction attributes "RequiresNew" >>in which case, a session bean can catch the transaction rolled back >>exception and then decide how to proceed further ... but that kinda >>complicates things from my perspective (business logic developer). >> >>Comments? >> >>-krish >> >> >> >>>-----Original Message----- >>>From: Evan Ireland [mailto:[EMAIL PROTECTED]] >>>Sent: Friday, January 25, 2002 9:40 PM >>>To: Krishnan Subramanian >>>Cc: [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 > >>> >>> >> > > > -- > ____________________________________________________________________________ > ___ > > 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". > > > > -- _______________________________________________________________________________ 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".
