.. _transaction_behavior:

Transaction Behavior
--------------------

The |VOSS-4-UC| transaction engine ensures that configuration changes are
made efficiently and reliably.

In the event of a transaction failure or error, |VOSS-4-UC| allows for
transactions to be rolled back to a state preceding the failed transaction.

For example, where a workflow step fails, all successful steps prior to a 
failed step are rolled back.

Transactions are hierarchical and have parent-child relationships with other
transactions. Sub-transactions are always executed sequentially and
synchronously, in other words the child transactions of a workflow parent transaction
are executed one after another.

Transaction behavior is different for the following actions in the system:

* API

  The API supports executing transactions in both synchronous and asynchronous
  modes. When executed in synchronous mode the API responds only once the
  transaction has completed. When executed asynchronously, the API responds
  immediately with a transaction ID so that the progress and status of the
  transaction can be polled.

* Bulk Loaders

  With bulk loading, the load of each row on a sheet is a separate transaction. 
  These transactions are run in series. There is no rollback of rows that have 
  loaded successfully prior to, or subsequent to, a failed transaction 
  (a failed row on a sheet). Multiple bulk load sheets can be loaded in parallel.


* Data Import

  A single transaction is created for each record in the import file. If a 
  single transaction fails, the import continues and does not roll 
  back the preceding successful transactions.

* Data Sync

  A single parent transaction is created for a data sync action. The subsequent
  device API requests are not handled as sub transactions but are executed
  in-line.

* Events

  Events can be triggered as part of data sync operations or as triggers on
  operations performed on certain model types. The provisioning workflow
  executed when the event triggers is executed as a new parent transaction.
  Transaction failures with the workflow executed after an event do not affect
  the original transaction that triggered the event.

All transactions are placed on a queue before they are actioned.
Parent transactions can run concurrently, but their subtransactions run serially.
There is priority in parent transactions so that user input such as adding on a GUI form
will be prioritized over a running import or bulk load process.



.. |VOSS-4-UC| replace:: VOSS-4-UC
.. |Unified CM| replace:: Unified CM