Oppolzer - Informatik / Blog

I don't know exactly, some speculation on my part, but:

if process B would return SQLCODE 100 and A would later ROLLBACK,
this would be very wrong, so I don't think this can happen. IMO process B must wait,
and I believe this is what happens. I think that the UPDATE of the index key from 4 to
6 is deferred until COMMIT of process A.

The key to this problem probably is the index type 2. With index type 2 there are no more
index locks; the locks are only on the data pages, but I think in this case the key 4 somehow
has to be flagged to give process B a signal that there is a concurrent writer that changed
the key (in the bufferpool), although not committed. The key 4 in the index has to be duplicated
anyway; maybe key 4 is left in place (and marked with a flag) and key 6 is inserted - at another
position in the index. Key 4 will be deleted on COMMIT ... ?

just a guess ...

Kind regards

Bernd



Am 07.09.2014 23:44, schrieb R.S.:
>
> Db2 experts,
>
> This question is related to Db2 Z/os.
>
> A table has an index defined on "col1" and lock size of the table
> space is "Page". There is an entry in the index with a value of "4"
> for "col1"
> Suppose process "A" changes the col1 value "4" to "6" and it has not
> issued commit yet. At the same time Process "B" tries to issue SELECT
> * from table where col1 = 4. And both processes uses CS isolation level.
>
> In this case,
> 1. will process "B" wait until Process "A" release the lock ?. If yes,
> as process "A" already changed the value of col1 to "6" from "4", how
> does process "B" know the provious value of col1, sothat it can find
> out that value "4" is already locked ?
> (or)
> 2. will process "B" return SQL code = 100 ?
>
> Thanks,
>
> R.
>
>
> -----End Original Message-----