Thanks for your help Victor, see below.
>Wrong. If this is true with some particular app server, it's a bug.
Concurrency
>control and transaction isolation are orthogonal concepts. If two
transactions
>violate serializeable isolation using optimistic concurrency control, then
at
>least one of the transactions will be rolled back.
>It depends on the app server and database you're using. If locking isn't
used,
>one transaction may rollback instead of blocking.
It occurs to me that this behavior is extremely important, and is
something that should be specified somewhere. How could one transaction
either block or rollback? As a developer trying to write portable code, it
is scary that I can't assume consistent behaviour on such a fundamental
issue to transaction processing as how to deal with serializeable
transactions. Maybe BEA made the right choice, I think it is much easier on
the developer's side of things if a transaction blocks, rather than rolls
back (and all the error handling required for this case).
Floyd
===========================================================================
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".
