Isolation level - interesting scenario

[Arun Srinivasan]

I am just confused because of the following scenario.

* I have turned on the new 8.2 registry variables skipdeleted,
skipinserted, evaluncommitted to ON
* I gave a select * from <>, it was waiting for a lock, it needed an
intent share lock on the particular table..
the lock that it was waiting on was eXclusive row lock that another
process(process-2) was having, process-2 was updating the table 500
rows at a time before
committing
* I was hoping this will not result because of the new registry
variables!!!!

I tried db2pd to get the isolation levels of the applications, but
with no joy...
How can I get the isolation level?

Thanx
Arun

[Ian]

Arun Srinivasan wrote:

I am just confused because of the following scenario.

* I have turned on the new 8.2 registry variables skipdeleted,
skipinserted, evaluncommitted to ON
* I gave a select * from <>, it was waiting for a lock, it needed an
intent share lock on the particular table..
the lock that it was waiting on was eXclusive row lock that another
process(process-2) was having, process-2 was updating the table 500
rows at a time before
committing

DB2_EVALUNCOMMITTED allows an application with CS/RS isolation to read
through a lock to determine if a row does not qualify (i.e. with a
SARGable predicate). Since your query is doing 'select * from <>' (no
predicates) DB2_EVALUNCOMMITTED doesn't apply.

* I was hoping this will not result because of the new registry
variables!!!!

No, you would have seen this same behavior before.

I tried db2pd to get the isolation levels of the applications, but
with no joy...
How can I get the isolation level?

See the EffISO column from -activestatements