Floyd,
I agree that the transaction behavior should be better specified. For instance,
a standard exception for concurrency conflicts would be good enhancement. By
standard exception I mean one specified in the EJB or JTS spec.
Even pessimistic concurrency could result in a deadlock which should throw a
standard exception. The container should have some provision for detecting these
conflict exceptions and retrying the transaction automatically. This behavior
would have to be optional since it may not be appropriate in all cases.
--Victor
Floyd Marinescu wrote:
> 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".
