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.

If the HADB node has no lock objects available, errors are written to the log file. .

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

• y is the session size (for session/modified session) or attribute size (for modified attribute),

  Then the number of records written to HADB is:

  xy/7000 + 2x

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

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:

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

Otherwise, the number of locks to be configured is:

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

Tuning NumberOfLocks

Start with the default value. Look for exceptions with the indicated error codes in the Enterprise 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.

  To change the number of locks, use the following command:

  hadbm set NumberOfLocks

  The hadbm restarts all the nodes, one by one, for the change to take effect. For more information on using this command, see Configuring HADB in Sun GlassFish Enterprise Server v2.1.1 High Availability Administration Guide.