Database Row Lock

This section describes the use of Database Row Locks for relational support.

A database lock will be acquired when the application issues a Read for Update (READU). Then the relational DB releases the lock after the transaction is committed or rolled back, which ensures no change at the application level, and the change happens in DCD. This change required immense testing to guarantee integrity, and to check performance. Two solutions have been investigated—using a lock table or DB’s own mechanisms directly.

The database row lock does the following.

• Move the reliance for the record lock to the Relational Database
• Remove the requirement for an independent record lock arbiter (JDLS)

COB Testing performed using the following.

• jDLS as a Baseline test
• Vendor lock API (dbms_lock or sp_getapplock/sp_releaseappl)
• T24LOCKTABLE to handle the lock requests

The following table shows the comparison, and the Vendor API solution seems to compare well with the existing JDLS performance. The graphs show the levels of contention on locks during COB. The higher the spikes, the more waiting is happening on locks. This bears out the figures on the left with the Vendor solution matching JDLS. As part of the benchmark activity, the performance of this under real client scenarios must be confirmed.

DBMS_LOCK (Vendor API)

JDLS Baseline