Starting and committing update transactions

Update transactions are started from within an application in order to be able to roll back a series of changes made within the transaction. Transactions are started for an object space. When running transactions within different object space handles referring to different access nodes for the same object space, transactions are not nested but will run asynchronously.

Otherwise, each call of beginTransaction() will cause a new nesting level for the transaction, which will be returned as transaction level. Each instance or index updated within a transaction will be locked (write lock) and stored to the transaction. All property handles having the object space as parent that has started the transaction, will get the updated state for the instances and indexes from the transaction buffer. Other applications referring to different object space handles will see the unchanged state until the transaction has been stored to database.

Changing indexes e.g. by adding or removing instances causes the index to be locked within the transaction. This may cause problems, when other applications try to create, delete or rename instances in the same collection, since indexes are locked. In order to avoid index locking, collection can be defined as shared in the schema definition, in which case indexes are not locked within the transaction, but key values, only.

One may commit or roll back transactions on any level. When committing a transaction (commitTransaction()), updates stored in the transaction will be moved up to the next higher transaction. When committing the top level transaction, data will be stored to the database and becomes available for other applications and users.