I don't know about other EJB servers but many O/R tools do dirty
checking. The one we're implementing does that if you're running in
optimistic mode, and does locking if you're running in pessimistic mode.
> Do any EJB implementations actually do dirty checks? I doubt it.
> Dirty checks are only appropriate if one expects long transactions.
Nope, dirty checking are a requirement if your entity beans are cached
in memory.
Think of the following scenario. You find an entity bean (i.e. load it
from the database), modify it and save it. Short transaction, everything
works fine. Then you start a new transaction using a cached copy of the
entity bean, which by now is out of synch with the database server.
Inside a transaction, the EJB server can always explicitly lock the
database to prevent concurrency problems. But once the bean has been
cached, dirty checks are a must.
arkin
> 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".
===========================================================================
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".
