Basic information

Transactions are provided in order to be able to perform several actions in the object database in a closed loop. If a number of operations in the object database are combined in one transaction, these can all be undone, for example, in the event of an error, by terminating the transaction. To do this, the operations in a transaction are kept in a transaction buffer until confirmation or termination, and are not stored immediately.

For the instance that started the transaction, the status of the object database is as if the object(s) had already been saved or deleted. Meanwhile, in multi-user mode, the object(s) from the object database is still valid for the other instances (clients of the GloServer).

Nested transactions are supported. Nested means here that another transaction can be initiated during a transaction. If this further transaction is cancelled, the system only rolls back to the last "start" of a transaction. All previous and further actions are executed when the transaction is "confirmed". This allows transactions to be encapsulated in units and used transparently in further transactions.

Examples:
Base.beginTransaction() >> Obj_ A->store() >> Base.beginTransaction() >> Obj_B->store() >> Base.abortTransaction() >> Base.commitTransaction()
Result: Only Obj_A is stored.

Base.beginTransaction() >> Obj_ A->store() >> Base.beginTransaction() >> Obj_B->store() >> Base.commitTransaction() >> Base.abortTransaction()
Result: No object is stored.

Base.beginTransaction() >> Obj_ A->store() >> Base.beginTransaction() >> Obj_B->store() >> Base.commitTransaction() >> Base.commitTransaction()
Result: Obj_A and Obj_B are stored.

Note: Objects that are to be saved or deleted in a transaction are locked from the transaction until it is finished. See also glo::LK_TRANSACTION_WRITE and glo::LK_TRANSACTION_DELETE. If an object in the transaction references an object dependent and/or the action (glo::BasePersistent::store (...) or glo::BasePersistent::deleteInBase (...)) was called with the corresponding parameter glo::EnDeepMode, the referenced object may also have been locked by the transaction.
A transaction does not protect against incorrect states. For example, if a client "1" has loaded an object "A" and another client "2" changes this object in a transaction, saves it and confirms the transaction, the unsuspecting client "1" can still make any changes to object "A" that may have been calculated from attributes and save it. This can be prevented by locking (see glo::BasePersistent::lock (...) ), then refreshing (see glo::BasePersistent::refresh() ), and only then changing and saving the object.

Starting the transaction

The start of a transaction can be initiated with glo::Base::beginTransaction(). Object database operations such as glo::BasePersistent::store (...) and glo::BasePersistent::deleteInBase (...) are not executed in the object database, but are kept in the transaction buffer.

Note: Queries such as glo::BasePersistent::refresh() respectively reloading an object stored during a transaction return the data for the instance that started the transaction from the transaction buffer. If the object has been deleted in a transaction, this object is no longer available in the object database for the instance that started the transaction. Meanwhile, in multi-user mode, the object is still valid from the object database for the other instances (clients of the GloServers).

Attention: The start of a transaction must always be terminated with glo::Base::commitTransaction() or glo::Base::abortTransaction(), otherwise the objects in the transaction will not be released. See also Confirm transaction and Cancel transaction.

Confirm transaction

A transaction can be confirmed via glo::Base::commitTransaction(). This means that all actions in the object database such as glo::BasePersistent::store (...) and glo::BasePersistent::deleteInBase (...) which have been initiated since the last start of the transaction are executed and then removed from the transaction buffer.

Cancel transaction

A transaction can be aborted via glo::Base::abortTransaction(). This means that all actions in the object database such as glo::BasePersistent::store (...) and glo::BasePersistent::deleteInBase (...) which have been initiated since the last start of the transaction are removed from the transaction buffer, i.e. not executed.

Note: The objects that have not been saved still have their possibly changed values. A glo::BasePersistent::refresh() is not executed automatically!