Just to be sure, so it is correct for local connection to pick up the global transaction's isolation level in the example scenario below?
> Within the global
> transaction, I change the isolation level to RS and then exit the global
> transaction so the connection is now attached to the local transaction.
> The isolation level at this point is set to RS rather than UR. This
 
thanks,
Mamta
 
On 8/3/05, Daniel John Debrunner <djd@debrunners.com> wrote:
Mamta Satoor wrote:

> Hi,
>
> From Dan's explanation on Derby-421 (starting an XA transaction resets
> the isolation level set with SET CURRENT ISOLATION) about various
> transaction states, what I understand is that local transaction and
> global transaction have to maintain their own states. I wrote a simple
> test program to check this behavior and it seems like Derby is not doing
> so.
>
> My test program gets a XA connection which is part of the local
> transaction. Derby's default isolation level is CS and that is what the
> connection object has at this point. I change the isolation level to UR
> within the local transaction. Now, the XA connection joins a global
> transaction. I had expected that the isolation level of the connection
> inside the global transaction would be the default isolation level CS
> but that is not the case, instead, it is set to the isolation level UR
> which is what the local transaction had it. Within the global
> transaction, I change the isolation level to RS and then exit the global
> transaction so the connection is now attached to the local transaction.
> The isolation level at this point is set to RS rather than UR. This
> seems incorrect. Any comments?

I think the behave you are seeing is correct and consistent with my
description in 421.

Any *new* transaction started by the application needs to pick up the
state of the application's Connection handle, which is what happens in
this case. The only issue comes when the application connects to an
*existing* global transaction with a different isolation level (or other
state).

Dan.