You can help to improve the efficiency of DATABASE 2 (DB2) operations by using the uncommitted read isolation level.
Queries are normally run with the default transaction isolation level: read stability. For DB2, the queries are optimized to run with uncommitted read, by default. However, when you need to ensure that the data displayed on work lists is completely accurate at the moment it is captured, use cursor stability.
To achieve complete accuracy, the database layer acquires read locks for all entities returned by a query. Concurrent update transactions are therefore blocked. This might not be desirable, under high load conditions.
You can switch business processes into a mode in which queries on DB2 are performed with the isolation level uncommitted read. This isolation level does not acquire read locks on the corresponding database tables. By using this isolation level, you can significantly improve concurrency. However, this approach introduces the risk that data can be displayed on a work list that is slightly out of date or is not yet committed. The throughput gains are significant, in most cases rendering acceptable the inaccuracy of the data, which, at worst, might cause a claim to fail because a work item has already been claimed.
By using uncommitted read, you can specify a different database transaction isolation level for the work item query on DB2, Universal Database (UDB), DB2 z/OS V7, or DB2 iSeries databases. For other databases systems, the transaction isolation level cannot be changed.
queryIsolationLevel=UR