Krishnan Subramanian wrote:
> Evan,
>
>
>>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).
>>
>
> I don't believe the spec invalidates deferred updates. (If it
> actually does suggest that deferred updates are not strictly
> valid, then I would be interested in the section where it does
> mention that).
The spec does not strictly "invalidate" deferred updates.
However the situation where a deferred update causes failure of
a session bean (running in the same transaction (before) the
deferred updates) it could be argued that the container has
failed to "synchronize the state when it needs to". The
relevant piece of the spec reads:
While the instance is in the ready state, the container can
synchronize the state of the instance with the state of the
entity in the underlying data source whenever it deter-mines
the need to, in the process invoking the ejbLoad() and ejbStore()
methods zero or more times.
So the argument goes thus:
(1) A session bean is accessing the entity's underlying database
representation in the same transaction (as a potentially
deferred update).
(2) Thereby the container needs to synchronize the state of the
entity before the session bean is called.
(3) Deferring any updates might result in the session bean seeing
a transaction-inconsistent view of the data.
(In this argument, you can replace session bean calls with finder
method calls, in the case where the container doesn't consult the
in-memory cache to get additional finder results during the transaction).
Now, as a developer, if you know this situation cannot arise, you
may be able to enable deferred updates during deployment. But I
believe it is hard to escape from the conclusion that deferred updates
are not a valid default behaviour (unless your app. doesn't have any
session beans or finder methods).
>>(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.
>>
>
> I believe the Container should call the ejbStore() on the newly
> created entity bean instance prior to executing step (2). This
> is required by the spec (and also what I suggested in my first
> posting - the write to the database would occur when some other
> transaction/bean wanted to work with that bean instance - say
> a finder method etc).
>
> So, in step (2), since the Container would be forced to write to
> the database - the session bean's query results would be consistent.
>
>
>>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'.
>>
>
> If the spec actually suggests that deferring database writes is
> not a valid (default) behavior . . . then you're probably right.
>
> -krish
>
> ===========================================================================
> 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".
