Locking and Concurrency

ElevateDB manages most locking and concurrency issues without requiring any action on the part of the user or developer. The following information details the steps that ElevateDB takes internally in order to maximize concurrency while still resolving conflicts for shared resources using locking.

ElevateDB performs locking in two different ways, depending upon whether global file I/O buffering is enabled in the ElevateDB engine. Please see the Buffering and Caching topic for more information on how the file I/O buffering works in ElevateDB.

How ElevateDB Performs Locking when Global File I/O Buffering is Disabled

When global file I/O buffering is disabled, all locks in ElevateDB are performed using calls to the operating system on the configuration lock file (EDBConfig.EDBLck), the database lock file (EDBDatabase.EDBLck), or the database table files themselves (*.EDBTbl). The *.EDBLck files are used for managing shared or exclusive object locks on users, jobs, databases, tables, views, and functions/procedures. The database lock file (EDBDatabase.EDBLck) is also used for managing table read, write, and transaction locks for all tables within the database. The *.EDBTbl files are use for both storing the rows of a table and locking the rows. If using a local session accessing an ElevateDB database on a network file server, these calls are then routed by the operating system to the file server's operating system.

If either the configuration lock file (EDBConfig.EDBLck) or the database lock file (EDBDatabase.EDBLck) does not exist and cannot be created due to issues with security permissions or read-only media, then the configuration or database will be treated as read-only and you will not be able to modify any objects contained within them.

ElevateDB takes advantage of the fact that modern operating systems allow an application to lock portions of a file beyond the actual size of the file. This process is known as virtual byte offset locking. ElevateDB restricts the size of any physical file that is part of a table to 128,000,000,000 bytes, or slightly below the maximum file size of 128GB. ElevateDB does this so it can reserve the space available between the 128GB mark and the 128,000,000,000 byte mark for row locks in the table.

How ElevateDB Performs Locking when Global File I/O Buffering is Enabled

When global file I/O buffering is enabled, ElevateDB will exclusively open any configuration, log, database catalog, and table files so that no other processes can open them. Doing this allows ElevateDB to buffer as much data as it needs to without worrying about changes being made by other processes. In addition, all locks in ElevateDB are performed using lock structures that are internal to the engine along with the configuration lock file (EDBConfig.EDBLck), the database lock file (EDBDatabase.EDBLck), or the database table files themselves (*.EDBTbl). The internal lock structures are used for managing shared or exclusive object locks on users, jobs, databases, tables, views, and functions/procedures. The database lock file (EDBDatabase.EDBLck) is also used for managing table read, write, and transaction locks for all tables within the database. The *.EDBTbl files are use for both storing the rows of a table and locking the rows using additional internal lock structures.

Row Locking Protocols

ElevateDB offers two types of row locking protocols, pessimistic (default) and optimistic locking.

Locking Protocol

Description

Pessimistic

The pessimistic row locking protocol specifies that a row should be locked when the row is retrieved for updating.

Optimistic

The optimistic locking protocol specifies that a row should be locked when any row modifications are posted back to the table. Using the optimistic row locking protocol for remote sessions removes the possibility that dangling row locks will be left on the ElevateDB Server if the application is terminated unexpectedly. However, even with the pessimistic row locking protocol, an ElevateDB server can clean up dead sessions and remove any row locks that they may be holding.

The two row locking protocols can safely and reliably be used among multiple sessions on the same database, although it is not recommended due to the potential for confusion for the developer or user of the application.

Row Locks

Row locks are used to enforce ElevateDB's pessimistic or optimistic row locking protocols and prevent the same or multiple sessions from updating the same row at the same time. Row locks block other row lock attempts, but do not block any reads of the locked rows. The following details what happens in the various scenarios that use row locks:

Action

Description

Inserting	When inserting a row, no row locks are acquired until the row is actually inserted. During the insertion of a new row, a row lock is only implicity acquired by ElevateDB on the new row if the insertion is taking place inside of a transaction.
Updating	When updating a row, a row lock is implicity acquired by ElevateDB. This row lock will fail if the row is already locked by the same session or a different session. If the row lock fails, then an exception will be raised. The error code that is raised when a row lock fails is 1005 (EDB_ERROR_LOCKROW). If the row locking protocol for the session is set to optimistic then ElevateDB will not attempt to implicitly acquire a row lock when the row is retrieved, but will instead wait until the row is actually updated to implicitly acquire the row lock. This means that another session is capable of updating or deleting the row before the current session actually completes the update. If either of these actions occur, an exception will be raised. The error code that is raised when an update fails because the row has been altered is 1008 (EDB_ERROR_ROWMODIFIED). The error code that is raised when an update fails because the row has been deleted is 1007 (EDB_ERROR_ROWDELETED).
Deleting	When deleting a row, a row lock is implicity acquired by ElevateDB. This row lock will fail if the row is already locked by the same session or a different session. If the row lock fails, then an exception will be raised. The error code that is raised when a row lock fails is 1005 (EDB_ERROR_LOCKROW).

The number of row lock retries and the amount of time between each retry can be controlled on a per-session basis. In a busy multi-user application it may be necessary to increase these values in order to relieve lock contention and provide for smoother concurrency between multiple users. However, in most cases the default values should work just fine. Please see your product-specific manual for more information on changing these settings for the session.

Table Locks

There are three types of table locks used by ElevateDB:

Type	Description

Table Read Locks	Table read locks allow ElevateDB to accurately treat reads on internal table structures, such as the indexes or BLOB columns, as atomic, or a single unit of work. Table read locks ensure that no other session writes to the table by blocking any table write locks. Table read locks are the most widely-used locks in ElevateDB and are the cornerstone of correct multi-user operation. They especially play a large role in change detection. Please see the Change Detection topic for more information. Table read locks are also acquired during table scans for un-optimized query conditions. Please see the Optimizer topic for more information on optimizing query conditions.
Table Write Locks	Table write locks allow ElevateDB to accurately treat writes on internal table structures, such as the indexes or BLOB columns, as atomic, or a single unit of work. Table write locks ensure that no other session reads from or writes to the table by blocking any table read lock or write locks.
Table Transaction Locks	Table transaction locks allow ElevateDB to treat single or multi-table updates within a transaction as atomic, or a single unit of work. Table transaction locks ensure that no other session begins a transaction on the table by blocking any other table transaction locks. Table read locks are allowed, however, and other sessions can read the rows from tables and acquire row locks. When a transaction is ready to be committed to disk, additional table write locks are acquired in order to block other table reads or writes while the data is being committed.

More Support Options

Support Forums

Frequently Asked Questions

Technical Bulletins

Technical Articles

Incident Reports

Roadmap