Working in Transactions

Operations with objects in Valuemation API are carried out in transactions opening access to the database. You can imagine a transaction as a logical unit of work or a block of operations carried out by a single user that defines a scope of work performed atomically by the database server.  Atomically means all or nothing: in other words, from the invoking of the transaction until its commit/rollback, all requests to modify the data in the database will be successful (committed) or fail together. This is done in order to ensure that related changes to a database either complete or fail as a consistent unit, and consequently, consistency of the database is always maintained providing that the system is working correctly. The reasons that can lead to canceling or a rollback of a transaction are various, most often it’s caused by an error during execution or by a user’s deliberate request for cancel.

Transaction access applies to all main permanently stored objects in API except BOTypes, Folders and MetaWorkflows. Of these, BOTypes doesn’t need transaction since it represents only metadata and Folders and MetaWorkflows use their special internal transaction. The transaction is also an object, for this reason it must always be created prior to creating other objects.

The transient objects, in other words, the objects that are not physically stored in a database and are only used for the sake of work within one session, cannot be created in transactions (see Creating Transient Objects) – such situation will inevitably result in an exception when you try to commit that transaction. You can check whether a given BOType is transient by calling ApiBOType.isTransient() before creating the object.