I believe the discussion of isolation levels in a cross-vendor context is
moot in the 1.1 spec, based on this statement:
"The API for managing an isolation level is resource manager specific.
(Therefore, the EJB
architecture does not define an API for managing isolation level.)"
> -----Original Message-----
> From: Rubens Gomes [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 26, 1999 9:07 PM
> To: [EMAIL PROTECTED]
> Subject: serializable transaction isolation level
>
> Could someone in this list verify the following
> Transactions scenarios? I am concerned on the
> validility of the data in TX_2 below.
>
> Here it is...
>
> A is an entity bean instance. 'attr' is an attribute of A.
>
> The underlying database supports isolation level serializable.
>
> TX_1 isolation level is READ COMMITTED.
> TX_2 isolation level is SERIALIZABLE
>
> ASSUMPTION: container implements PESSIMISTIC locks on entities.
>
> A.attr = '0' (before transaction TX_1 started)
>
> (begin) (A.attr='1' ) (commit)
>
> TX_1: |--------------****----------|
> (begin) (read A.attr) (A.attr = '2') (commit)
> TX_2: |--------------***----------****-----------|
>
> --------t1---t2--------t3----t4-----t5----t6------------t7-->
> (time)
>
> Here is how I see the above two transactions at different
> points in time. Please, confirm if this is valid in the
> EJB entity context.
>
> at time t1, TX_1 sees A.attr as '0'
> at time t2, TX_2 sees A.attr as '0'
> shortly after time t3, TX_1 sees A.attr as '1'
> at time t4, TX_2 is blocked, and the TX_2 thread waits for
> the pessimistic lock on A to be released
> at time t5, TX_1 commits TX, and pessimistic lock on entity
> bean A is released.
> shortly after time t5, TX_2 thread can proceed, and reads A.attr.
> What value does TX_2 read here ? I would expect it to be
> '0', NOT '1' because TX_2 is a SERIALIZABLE TRANSACTION.
> But I wonder if WebLogic or any other EJB container supports
> this, since the isolation levelis delegated to the database.
> at time t6, TX_2, updates A.attr to '3', no exception is thrown here
> yet, because TX has not commited and ejbStore not called yet.
> at time t7, TX_2 tries to update state of A to database calling
> ejbStore. But a serializable exception is thrown by underlying
> database at time t7. TX_2 cannot be serialized due to TX_1
> update/commit of record A after TX_2 started, and before
> TX_2 tried to update that same record.
>
>
>
> Rubens.
>
> ==========================================================================
> =
> 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".
