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
>
>
===========================================================================
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".
