deadlock - DB2 Read committed without locking? -


we have transaction modifying record. transaction must call web service, rolling transaction if service fails (so can't commit before hand). because record modified, client app has lock on it. however, web service must retrieve record information part of it's processing. bam, deadlock.

we use websphere, which, reasons boggle mind, defaults repeatable read isolation level. knocked down read_committed, thinking retrieve row without seeking lock. in our dev environment, seemed work, in staging we're getting deadlocks.

i'm not asking why behaved differently, made mistake somewhere. nor asking specifics of web service example above, because same thing happen elsewhere.

but based on reading docs, seems read_committed acquire shared lock during read, , result wait exclusive lock held transaction (in case client app). don't want go read_uncommitted isolation level because don't want dirty reads. there less extreme solution? need middle ground can perform reads without lock-waiting, , retrieve committed data.

is there such goldilocks solution? not deadlock-y, not dirty-read-y? if not in siolation level, maybe modifier can tack onto sql? anything?

i assume talking jdbc isolation levels, , not db2. difference between read_committed (cursor stability in db2) , repeatable_read (read stability) how long share locks kept. repeatable_read keeps every lock satisfied predicates, read_committed on other hand keeps lock until row matches predicate found.

have compared plans? if plans different may end different behaviour.

are there escalations occurring?

have tried currently_committed (assuming on 9.7+)?

pre currently_committed there following settings, db2_skipinserted, db2_evaluncommitted , db2_skipdeleted


Comments

Popular posts from this blog

database - VFP Grid + SQL server 2008 - grid not showing correctly -

jquery - Set jPicker field to empty value -

.htaccess - htaccess convert request to clean url and add slash at the end of the url -