Concurrency behavior

In order to avoid concurrency problems, ODABA provides internal and external locking and transaction features. Depending on handle access mode, ODABA forbids or permits concurrent instance update. An automatic update detection discovers and "repairs" conflicts in case of concurrent updates.

In order to make concurrent applications save, but also for improving performance (e.g. for maintenance processes), ODABA provides different transaction technologies:

• Internal transactions - very short transactions started internally while running any update function.
• Read transaction - started in order to block event generation (e.g. while iterating through a collection).
• Pool transaction - Medium transaction storing changes in an internal area
• File transaction - Long transaction storing changes in a file.
• Work spaces - Very long transactions storing changes in hierarchical staging areas.

In order to restore changes made after last backup, a recovery file may be written, which logs all transactions.

In order to avoid concurrent updates, instances and indexes can be locked (read or write lock) temporarily. Several internal and external lock features are provided:

• Implicit locks - are very short locks mainly used for indexes/collection updates. All resources updated within a transaction are locked until the end of transaction. Instances are also locked implicitly (write lock), when being read in write mode.
• Read locks - read locks may be called by applications in order to prevent a resource from being read or updated by other processes or transactions.
• Write locks - prevents an instance or collection from being updated by other processes or threads
• Persistent locks - allows locking an instance or collection in the database permanently (write lock).
• Key locks . special lock mechanism in order to reduce write lock time for collections (indexes) in longer transactions.

There are some other types of locking global resources described in User's Guide and Reference Documentation .