Specifies whether a read-only query can access the currently committed value of rows that are locked by a transaction that is updating the rows. The driver must be connected to DB2 V9.7 for LUW or higher and the application isolation level must be either read committed or repeatable read.
Valid Values
0 | 1 | 2
Behavior
If set to 0 (Automatic), the driver persists the server behavior, as specified by the cur_commit server parameter. If cur_commit is set to "Available" or "Disable," then the current behavior, pending until the row lock is released, is used. When cur_commit is set to "On," the driver returns the last committed value of the row, regardless of whether the row is locked.
If set to 1 (Wait For Outcome), the driver always waits for the transaction to be completed before returning a row of data that has been locked by another transaction, regardless of how the cur_commit parameter is configured on the server.
If set to 2 (Use Currently Committed), the driver returns the value that was committed during the last transaction if the cur_commit parameter is configured to "On" or "Available," even though the row is locked.
Notes
This option is ignored when connecting to a DB2 server version earlier than DB2 V9.7 for LUW.
DB2 V10 for z/OS and DB2 for i 7.1 using DRDA do not currently support reading committed data while performing UPDATE statements. In this scenario, transactions always wait for a commit or rollback operation if they encounter data that is being updated or deleted.
This option is ignored when connecting to a DB2 server version earlier than DB2 V9.7 for LUW.