Can someone confirm DB2 does not act like Oracle in the case below with the settings below?


2. If DB2 behaves like Oracle, then the committed transaction is placed on a queue to be updated and that did not occur before the next query.


[i] DB2_SKIPINSERTED=ON
[i] DB2_SKIPDELETED=ON

Thanks

No, it does not.

This affects the rows that have been inserted or deleted but not committed yet. These rows are locked, and normally a query with a sufficient isolation level would block when hit one of such rows. The two registry variables change that behaviour so that the query skips uncommitted rows.

When the transaction commits all its locks are released.

As already noted, the two environment settings do not make DB2 work the same as Oracle with regard to locking. However, the parameters do have the benefit of increasing concurrency and reducing DB2 lock contention, so it shares some advantages with Oracle in that regard. An even though these parameters do not make DB2 the same as Oracle, they increase concurrency a lot more efficiently than the Oracle optimistic locking and read consistency scheme.