|
The DEX_LOCK table is used to track only active locks. If your application doesn’t implement active locking, you can skip this section. |
Dexterity uses the DEX_LOCK table to track active locks acquired on records. This table must be located in the standard SQL Server database named tempdb, and be defined to include the following columns with the specified attributes:
|
Column name |
Type |
Length |
Nulls |
Identity column |
|---|---|---|---|---|
|
session_id |
int |
4 |
0 |
NO |
|
row_id |
int |
4 |
0 |
NO |
|
table_path_name |
char |
100 |
0 |
NO |
This table’s primary key is based on a combination of the row_id and table_path_name columns. The other column in this table, the session_id column, contains the session ID generated by the DEX_SESSION table, identifying the user who has the specified record locked.
Each time a user locks a record, a row is inserted in the DEX_LOCK table containing the following information:
Since the DEX_LOCK table’s primary key is based on the row ID and table pathname, and since primary keys do not allow duplicate entries with the same key values, a single record cannot be referenced in this table more than once at any given time. This prevents multiple users from actively locking a single record simultaneously.
When the lock on a given record is released, the row related to that record is deleted from the DEX_LOCK table. When the row is removed from the table, the record’s row ID and the pathname of the table containing the record will no longer be key values in the DEX_LOCK table. Thus, another user may actively lock the record.