> >Are there other possibilities for the db
> >to handle that problem which avoid the deadlock?
>
> I would guess that transaction commits are atomic. Apply as necessary to
> above scenario for solution.
>
> If some DB fellow (Evan?) could confirm this that'd be great.
>
> /Rickard
This thread has really gotten off the EJB track. Part of the "problem" is
that people need to talk about some real products and implementations since
most of us are concerned more with what can be done using EJBs today than
what could be done in a theoretically environment.
For example, most people still use RDBMS, though OODBMS may solve many
problems, even if they create others. Locking is still the main way today's
DBMS will handle concurrency issues and avoid lost updates, for example.
That's just the model most have used to implement transactional ACID
properties.
This also shows that there are real-world problems with the EJB spec at this
point. If there's this much confusion about locking and such with the DB,
imagine the likelihood that a working app could really be picked up from one
EJB container and moved to another and have it all work out. Clearly, there
are many issues that fall back to the persistence mechanism used, and EJB
attempts to resolve these to make portability and interoperability better.
David
===========================================================================
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".
