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