I've always thought that READ_COMMITTED (DB2 calls it Cursor Stability (CS)) meant that you do NOT lock on reads, and that you only read the committed data. A situation just came up that makes me realize that DB2 is locking, albeit very briefly, on reads in CS.
Because it's brief, that makes it vulnerable to deadlocking. We have a client code that updated row X, then calls a web service that, among many other things, needs to read row X. Because the client code need to be able to rollback if the web service fails, it must hold that lock during the web service call.
With the service running at READ_COMMITTED, I thought it would not wait for the record, but would just read the old data and continue (which is fine).
Is there a way, short of running in READ_UNCOMMITTED (which gives me the willies) to make my service NOT go into lock-wait on a read event? I am primarily operating theough java & hibernate, but if you know tricks purely from a DB2 side even that would be informative.
