<snip>
>>> 3. What if other systems (i.e. batch processes that run outside of
>>> the EJB application) update application data? Does that mean my data
>>> in my "in memory" entity beans will essentially be stale? I would
>>> think so, unless the ejbLoad() method is always triggered and
>>> therefore the DB is always hit.
>>
>> So long as the container is not using commit option A (I suspect that
>> all containers that support option A also support options B or C), the
>> ejbLoad() method is always triggered (once per transaction; a
>> transaction may span several business method calls).
On 12/30/1999, Assaf Arkin wrote:
> Even that is not very helpful, unless you use pessimistic locking.
> Unless the object is locked, it could be changed while the entity bean
> is executing.
Optimistic locking can deliver correct results. The only difference is
what happens when there is update contention. With pessimistic locking,
later updaters wait for earlier ones to complete, then they will proceed.
With optimistic locking, the first update goes through, any conflicting
updates are aborted to preserve transactional isolation.
> The two solutions are explicit locking (i.e. lock object when starting
> entity bean method) and dirty checks (i.e. check database copy against
> cached copy to determine external modification). A good CMP engine
> should support both.
Do any EJB implementations actually do dirty checks? I doubt it.
Dirty checks are only appropriate if one expects long transactions.
In general, EJB is intended for scaleable systems, where transactions
must be short.
- Bruce
===========================================================================
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".
