Multithreaded Programming With the DevKit
The DevKit is designed to be used in a multithreaded environment. It takes care of ensuring that all of the in-memory data objects are accessed and updated in thread safe manner. Applications using the DevKit need not worry about controlling access to these objects. However, it might be useful to understand the locking that goes on when the DevKit commands are called. This section describes that locking at a high level.
Thesauri, Character Maps, and Learn Models are all immutable objects. They cannot be updated or modified after they are created. This simplifies their management. The locks associated with adding, deleting, and accessing these objects are held so briefly that they have no impact on an application. An exception might be when checkpointing these objects, the tracking data for checkpoints might have to be held locked for a noticeable period of time. This can block some other operations that must access the checkpoint data.
If checkpointing is enabled, any operation that adds, deletes or renames an in-memory object (database table, thesaurus, character map, Learn Model) must write lock the checkpoint data while the operation is performed. In addition the checkpoint operation must write lock the checkpoint data. The restore operation must read lock the checkpoint data. The duration of the locks are kept to a minimum, but any of these operations can create contention issues in a heavily loaded system.
Database tables can be modified and therefore must be locked while being used. Locking is at the table level, not the individual record level. Any number of threads can read a table in parallel, but update operations require an exclusive lock on the table; they must lock out all other operations, both read and update, while the update is performed. In applications that have multiple threads both reading and updating a table, this can create contention issues.
Operations that add, delete, or rename a table must update the information on the set of tables in memory. All other operations trying to access a table are locked out while that information is being updated. These locks are held briefly (not for the duration of the entire command), but might still create contention issues as they block all other commands that access tables.
The following important classes of locks are involved:
| • | Locks on the Checkpoint Data: conceptually there is a single lock. This comes into play only when checkpoint or restore is enabled. Generally, commands hold this lock only briefly. |
| • | Locks on the index of Database Tables: this controls operations adding, deleting or renaming tables. Conceptually there is a single lock. Generally, commands hold this lock only briefly. |
| • | Locks on individual Database Tables: this controls access to an individual table. There is a separate lock for each table. Commands must hold this lock for the duration of the command. |
Additional locks are used for the indexes of the thesauri, Learn Models, and custom character maps that are loaded on the server. These locks are held only briefly, and in most applications are used rarely, hence they have negligible impact on the performance.
Each of these locks can be read locked or write locked. Any number of threads can hold a read lock, but a write lock is exclusive, no other thread can have a read lock or write lock.
In the following table the entry:
| • | "-" indicates no lock is used |
| • | "R" indicates a read lock is used |
| • | "W" indicates a write lock is used |
| • | "V" indicates the lock used varies - this pertains to the transaction commit and abort commands, the locks needed depend on the operations within the transaction. |
The table lists all of the DevKit commands that use one of the classes of locks described above.
|
Command |
Checkpoint Lock |
Database Index Lock |
Database Table Lock |
|
lkt_dbload |
R |
W |
- |
|
lkt_dbdelete |
W |
W |
R |
|
lkt_dbmove |
W |
W |
W (source) R (dest) |
|
lkt_dbrecget |
- |
R |
R |
|
lkt_dbrecadd |
- |
R |
W |
|
lkt_dbrecdelete |
- |
R |
W |
|
lkt_dbrecreplace |
- |
R |
W |
|
lkt_dbrecupdate |
- |
R |
W |
|
lkt_dblist |
- |
R |
R |
|
lkt_idxlist |
- |
R |
R |
|
lkt_dbdump |
- |
R |
R |
|
lkt_dblock |
- |
R |
W |
|
lkt_dbunlock |
- |
R |
W |
|
lkt_dbsearch |
- |
R |
R |
|
lkt_delete_thesaurus |
W |
- |
- |
|
lkt_delete_rlmodel |
W |
- |
- |
|
lkt_checkpoint |
W |
R |
R |
|
lkt_restore |
R |
W |
R |
|
lkt_tran_commit |
V |
V |
V |
|
lkt_tran_abort |
V |
V |
V |
|
lkt_dbrecnext |
- |
R |
R |