Isolation level ignored when DTC is used

[yu_sha]

Hello everyone

We have a bunch of components registered under COM+ with 'transaction
required' option.

On the client we are using iSeries Access 5.2.0, with all possible
fixes applied (Service level SI16136, iSeries ODBC driver version
9.00.09.00).

Server is DB2/AS400 05.02.0001 (that's what ODBC driver reports. So, I
guess it's V5R2.1 or something like this). Server is actually outside
our control (belongs to customer). We can suggest some changes to the
customer, but first we need to understand what's going on.

Here's what happens (I stripped tables and statements to the bone):

1) Before tests, we create a table. Like this
Create table test
(ID integer primary key,Node integer,Q integer)

2) and insert two records:
INSERT into test (id, node, q) values (11, 1, 0)
INSERT into test (id, node, q) values (12, 1, 1)

3) Now we call component A. It establishes a connection to our DB2,
which is enlisted into DTC.

4) Component A does an update:
UPDATE test SET q=0 WHERE id=12

5) Component A continues... In this example, it just goes to sleep.

6) At this point, of course, the second record is locked and 'dirty'.
So, should another transaction see it? Depends on isolation level,
right? We set Isolation level for DSN as 'Repeatable Read (*ALL)'.

7) Component B (transaction B) is called
SELECT * from TEST where node=1 and q=0

8) It returns an EMPTY recordset. It beats me, why it does not return
the first record (11, 1, 0).

Since I don't know much about DB2, I tried the same client, same
components, same settings, but against a different database. This one
is also a V5R2, but full version number is 05.02.0009.

In this case component B sensibly waits till transaction A ends, and
then returns only the first record! That's what I expect from it!

Does any DB2 guru here know
- What should we look into? Server config? Network config? Any clues in
trace files?
- Does 05.02.0001 support all the isolation levels?
- Are there any known issues between 5.2.0001 and MS DTC that make it
desirable to upgrade the server to 5.2.0009?

Thank you in advance
Yury Shatz
(yury.shatz@__nospam__.usa.net)

[Mark A]

"yu_sha" <yu********@usa.net> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Hello everyone

We have a bunch of components registered under COM+ with 'transaction
required' option.

On the client we are using iSeries Access 5.2.0, with all possible
fixes applied (Service level SI16136, iSeries ODBC driver version
9.00.09.00).

Server is DB2/AS400 05.02.0001 (that's what ODBC driver reports. So, I
guess it's V5R2.1 or something like this). Server is actually outside
our control (belongs to customer). We can suggest some changes to the
customer, but first we need to understand what's going on.

Here's what happens (I stripped tables and statements to the bone):

1) Before tests, we create a table. Like this
Create table test
(ID integer primary key,Node integer,Q integer)

2) and insert two records:
INSERT into test (id, node, q) values (11, 1, 0)
INSERT into test (id, node, q) values (12, 1, 1)

3) Now we call component A. It establishes a connection to our DB2,
which is enlisted into DTC.

4) Component A does an update:
UPDATE test SET q=0 WHERE id=12

5) Component A continues... In this example, it just goes to sleep.

6) At this point, of course, the second record is locked and 'dirty'.
So, should another transaction see it? Depends on isolation level,
right? We set Isolation level for DSN as 'Repeatable Read (*ALL)'.

7) Component B (transaction B) is called
SELECT * from TEST where node=1 and q=0

8) It returns an EMPTY recordset. It beats me, why it does not return
the first record (11, 1, 0).

Since I don't know much about DB2, I tried the same client, same
components, same settings, but against a different database. This one
is also a V5R2, but full version number is 05.02.0009.

In this case component B sensibly waits till transaction A ends, and
then returns only the first record! That's what I expect from it!

Does any DB2 guru here know
- What should we look into? Server config? Network config? Any clues in
trace files?
- Does 05.02.0001 support all the isolation levels?
- Are there any known issues between 5.2.0001 and MS DTC that make it
desirable to upgrade the server to 5.2.0009?

Thank you in advance
Yury Shatz
(yury.shatz@__nospam__.usa.net)

DB2/400 is a sometimes different from the other DB2's, and not many DB2/400
experts post here, but here a few comments on your post based on DB2 in
general (not specifically DB2/400).

Isolation level determines how long read (share) locks are held.. It has no
effect on update locks, which are always held until a commit or rollback
takes place. Of curse, isolation level UR (uncommitted read) ignores most
locks. With repeatable read, share locks are also held until a commit
occurs.

Are you sure that your component B is not receiving an SQL error (such as
lock timeout) during the select?

[yu_sha]

> Of curse, isolation level UR (uncommitted read) ignores most

locks. With repeatable read, share locks are also held until a commit
occurs. I realize this. So, I fully expected my 'select' component to block on
a locked row and wait for transaction A to end. Which is what happens
on another database.
Are you sure that your component B is not receiving an SQL error (such as lock timeout) during the select?

Well, I am certainly not getting any error from ADODB. I am even
getting a recordset with the fields (but no rows). I've never seen
ADODB or ODBC 'hiding' error from the client so it is safe to assume
the database actually returns this recordset.

When I turned iSeries diagnostic tools on, I did not see anything
suspicious in the log, either.

Do you know where I can find some sort of change log between V5R2.0001
and V5R2.0009?

[Ionut Filip]

> 8) It returns an EMPTY recordset. It beats me, why it does not return

the first record (11, 1, 0).

What it beats me is why it doesn't timeout
With a RR isolation and 2 rows in the table, i think the access plan will
try a shared lock at the table level, which will conflict with the X lock on
the updated record.
I don't think there is any way that you can fetch anything from that table
at RR unless you create some index and make the optimizer use it

[Fan Ruo Xin]

Don't know about DB2/400. If like db2 udb for LUW, suppose db2/400 also
supports statment isolation level, you should try using this way to re-run
the test. Sometimes for whatever reason, when you set the isolation level
for the whole session or the whole transaction, it might not take effect and
it is hard for you to verify. I tried to find out the isolation level of a
java program and finally gave up.
The second thing is you should check if the isolation level RR for ODBC does
match db2/as400's isolation level RR. Just like standard JDBC API which can
talk to DBMS from different vendor. The under ODBC driver will take care of
the conversion.

"yu_sha" <yu********@usa.net> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Of curse, isolation level UR (uncommitted read) ignores most
locks. With repeatable read, share locks are also held until a commit
occurs.

I realize this. So, I fully expected my 'select' component to block on
a locked row and wait for transaction A to end. Which is what happens
on another database.

Are you sure that your component B is not receiving an SQL error

(such as

lock timeout) during the select?

Well, I am certainly not getting any error from ADODB. I am even
getting a recordset with the fields (but no rows). I've never seen
ADODB or ODBC 'hiding' error from the client so it is safe to assume
the database actually returns this recordset.

When I turned iSeries diagnostic tools on, I did not see anything
suspicious in the log, either.

Do you know where I can find some sort of change log between V5R2.0001
and V5R2.0009?

[yu_sha]

> What it beats me is why it doesn't timeout
You are right, of course. It should timeout. I tried RR, ALL and CS
isolation levels, with the same results. With CHG isolation level it
returns both rows, this makes sense.

With a RR isolation and 2 rows in the table, i think the access plan will try a shared lock at the table level, which will conflict with the X lock on the updated record.
By the way, if I insert 10000 rows, nothing changes.
I don't think there is any way that you can fetch anything from that table at RR unless you create some index and make the optimizer use it

It's OK if it blocks. This is a low priority loop on the server that
looks for the next jobs to execute - it'll fetch something next time.

I started investigating this when query (more complex than this one)
returned 'both' rows - including a dirty one - under RR isolation
level. Which is completely unacceptable. Empty recordset is acceptable,
but weird and I believe it to be manifestation of the same problem.

By the way, on Oracle and MS SQL we use SKIP LOCKED hint for this
purpose. No such think on DB2, as far as I understand?

[yu_sha]

> Sometimes for whatever reason, when you set the isolation level

for the whole session or the whole transaction, it might not take effect and it is hard for you to verify.

I though about that, but writing "WITH RR" or "WITH ALL" or "WITH CS"
on the end of SELECT gives exactly the same results.

By the way, "Read Uncommitted" works differently so Isolation Level
does have some effect.

<<The second thing is you should check if the isolation level RR for
ODBC does match db2/as400's isolation level RR>>
That's actually a DB2 iSeries ODBC driver's setting. So I guess it
matches.

What I was thinking is - perhaps this database does not support these
high isolation levels at all, because it's an old version or because
it's configured that way. How do I find out?

[Knut Stolze]

yu_sha wrote:

What it beats me is why it doesn't timeout

You are right, of course. It should timeout.

It depends on the configuration of the lock-timeout. If that is still set
to -1, then DB2 will wait until the universe collapses (or an interrupt is
received). In other words, it won't time-out.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

[Fan Ruo Xin]

"yu_sha" <yu********@usa.net> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Sometimes for whatever reason, when you set the isolation level
for the whole session or the whole transaction, it might not take

effect

and it is hard for you to verify.

I though about that, but writing "WITH RR" or "WITH ALL" or "WITH CS"
on the end of SELECT gives exactly the same results.

By the way, "Read Uncommitted" works differently so Isolation Level
does have some effect.

<<The second thing is you should check if the isolation level RR for
ODBC does match db2/as400's isolation level RR>>
That's actually a DB2 iSeries ODBC driver's setting. So I guess it
matches.

What I was thinking is - perhaps this database does not support these
high isolation levels at all, because it's an old version or because
it's configured that way. How do I find out?

The easier way to do this - you just need to cature the explain information
of a simple query, like the following:
"select * from <tbl> where <colname> = 'xxx' with rr"
from db2 command line.
Then from the explain output, you can find out the isolation level
information.

[yu_sha]

It does not wait it does not timeout - it quickly returns results that
are wrong.