Transactions

The use of transactions allows to run multiple operations in parallel. Imagine a rendering is running when a user starts to edit a scene and for example moves some geometry. If this change would immediately affect the ongoing render operation then the resulting image would be corrupt, because in some parts of the image the geometry would be still in the old position and in some parts it would be in the new position.

To avoid this the Iray database uses transactions to provide a consistent view on the database for the lifetime of a transaction. Before a rendering is started a new transaction is created and all accesses and changes to the database are done through that transaction. Changes from transactions which were not committed before the rendering transaction was started would not be visible to that transaction. In databases this is known as the Isolation property.

Additionally it is possible to commit or abort a transaction. If a transaction is committed, all changes to the transaction become visible at the same time for all transactions that are created after the commit. If the transaction is aborted, all changes in the transaction are automatically abandoned and will not be visible for any other transactions. This is known as the Atomicity property.

Transactions fully work on distributed clustered systems, and each of the nodes in a system is able to start and commit transactions and use them for operations.

Note that the neuray database does not provide the Durability property of conventional databases. All storage is done to main memory for fast operation. In the case of memory overusage, neuray can offload stored data to a disk. This is not meant to be done for persistent storage. Using external code, you can write data to conventional databases or plain files or read data from them.

Transactions are created from a scope, which in turn is created from the database. A transaction is represented with the mi::neuraylib::ITransaction interface in the API.