3. Transactions - Transactions in an object space

ODABA supports read and write transactions. Read transactions can be started in order to cache events while running complex tasks. Since events are optimized within the cache, only relevant events are emitted, when terminating a read transaction.

When creating a write transaction ( beginTransaction() ), all modification for the object space are stored in a transaction buffer. ODABA automatically detects, whether instances or indexes have been modified and need to be stored to the database. In case of running a transactions, changes are stored temporarily in a transaction buffer. Database entry stored in a transaction buffer are locked (write lock) for other processes and cannot be changed as long as the transactions is running.

A transaction can be created as an internal or external transaction. Internal transactions are created for short transactions up to 10000 updated database entries. Usually, short transactions take less than 10 second, which is the timeout for accessing locked instances.

Internal transactions might also be created in for increasing access performance. In order to limit transaction locking, the transaction buffer size can be limited. Thus, a dynamic transaction buffer will be defined, which will be cleared automatically when the buffer size is exceeded. Since it is always faster reading instances from a transaction buffer, the transaction buffer works like a simple cache for processed instances.

External transactions are stored in a transaction database which is created in a path defined in the TABASE option (or configuration file). External transactions are slower than internal ones, but they are not limited in capacity.

Transactions can be nested. When starting a transaction while another transaction is running the new transaction creates a transaction within a transaction. The current nesting level is returned as transaction level when creating a transaction ( beginTransaction() ). Entries, which are stored in a transaction are locked for other users until the top transaction has been terminated.

In order to save updates in a transaction, commitTransaction() has to be called. In case of nested transactions, the transaction content will be moved to the upper transaction. In case of committing a top level transaction, the transaction content is stored to database. Updates made within a transaction become visible in an upper transaction when the transaction is committed. They become visible for other users when the top transaction is committed.

In order to discard modifications stored in a transaction, rollBack() can be called, which will undo all updates made within a transaction.