NumberOfLocks

Each row level operation requires a lock in the database. Locks are held until a transaction commits or rolls back.
Locks are set at the row (BLOB chunk) level, which means that a large session state
requires many locks. Locks are needed for both primary, and mirror node operations.
Hence, a BLOB operation allocates the same number of locks on two HADB nodes.

When a table refragmentation is performed, HADB needs extra lock resources.
Thus, ordinary user transactions can only acquire half of the locks allocated.

Calculating the number of locks

To calculate the number of locks needed, estimate the following parameters:

Number of concurrent users that request session data to be stored
in HADB (one session record per user)

Maximum size of the BLOB session

Persistence scope (max session data size in case of session/modified
session and maximum number of attributes in case of modified session). This requires setAttribute() to be called every time the session data is modified.

If:

x is the maximum number of concurrent users,
that is, x session data records are present in the HADB, and

Record operations such as insert, delete, update and read will use one lock
per record.

Note –

Locks are held for both primary records and hot-standby records. Hence,
for insert, update and delete operations a transaction will need twice as many locks
as the number of records. Read operations need locks only on the primary records.
During refragmentation and creation of secondary indices, log records for the involved
table are also sent to the fragment replicas being created. In that case, a transaction
needs four times as many locks as the number of involved records. (Assuming all queries
are for the affected table.)

Summary

If refragmentation is performed, the number of locks to be configured is:

Nlocks = 4x (y/7000
+ 2) = 2xy/3500 + 2x

Otherwise, the number of locks to be configured is:

Nlocks = 2x (y/7000
+ 2) = xy/3500 + 4x

Tuning NumberOfLocks

Start with the default value. Look for exceptions with the indicated error codes
in the Application Server log files. Remember that under normal operations (no ongoing
refragmentation) only half of the locks might be acquired by the client application.

To get information on allocated locks and locks in use, use the following command:

hadbm resourceinfo --locks

For example, the output displayed by this command might look something like
this:

Node No. Avail Free Waits
0 50000 50000 na
1 50000 50000 na

Avail: Number of locks available.

Free: Number of locks in use.

Waits: Number of transactions that have waited for a lock.“na”
(not applicable) if all locks are available.