A transaction is an indivisible unit of work and it is used to ensure data integrity. Transactions control the concurrent access of data by multiple programs. In the event of a system failure, transactions ensure that after recovery the data is in a consistent state. All operations on a persistent class need to be carried out within a transaction. Transactions are started automatically and all changes are persisted in-memory. A transaction can end in two ways: with a commit or a rollback. OpenAccessContext.SaveChanges() attempts to save all the changes to the database, however, if any statement within the transaction fails, the transaction is rolled back, undoing all the effects of the statements in the transaction.
Operations on persistent classes in a database are always performed in the context of a transaction. A transaction is an ordered sequence of operations that transforms a database from one state of consistency to another state of consistency. The data in Telerik Data Access is maintained in a transactional consistent state according to the standard definition of ACID transactions:
- Atomicity - the Atomicity property states that within a transaction, changes to the values in persistent instances are either executed in their entirety or they are not executed at all, i.e. if one part of the transaction fails, the entire transaction fails. A transaction, therefore, must not leave intermediate states in the databaseâ€”even when errors occur.
- Consistency - the Consistency property states that before the beginning and after the end of a transaction, the state of a database must be consistent. This means, in particular, that after the rollback of a transaction, (the transaction was not successfully processed due to an error) the consistent state of the database must be reestablished. Telerik Data Access assures that changes to the values of persistent instances are consistent with changes to other values in the same instance. Telerik Data Access, however, does not assure referential integrity; i.e., references to other persistent instances can always be resolved.
- Isolation - the Isolation property requires that changes to values in persistent instances are isolated from changes to the same instance in other transactions. For a given transaction, it should appear as though it is running independently from all other transactions associated with the database.
- Durability - the Durability property states that if a transaction has been committed successfully, all its changes must be durable in the database, i.e. any transaction committed to a database will not be lost. This is guaranteed by the database backend (for some databases, the backend may be disabled or may not be available).
In order to write changes to the database you need to call the SaveChanges method of the context.
To rollback all changes in the context, the ClearChanges method of the context should be used.