[Expand]General Information
[Expand]WinForms Controls
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]ASP.NET Core Bootstrap Controls
[Expand]WPF Controls
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Office File API
[Expand]Reporting
[Expand]Report and Dashboard Server
[Expand]Dashboard
[Expand]eXpressApp Framework
[Collapse]eXpress Persistent Objects
 [Expand]Product Information
 [Expand]Getting Started
 [Expand]Fundamentals
 [Expand]Feature Center
 [Collapse]Concepts
   Basics of Creating Persistent Objects for Existing Data Tables
   Creating a Persistent Object
   Creating a Session
   Creating an XPCollection
   Custom Collection Types
   Deferred and Immediate Object Deletion
   Explicit Units of Work
   Filtering Basics
   Generating Persistent Objects for Existing Data Tables
   How to: Add Persistence to an Existing Hierarchy by Changing the Base Inheritance
   How to: Add Persistence to an Existing Hierarchy by Using Session-less Persistent Objects
   How to: Connect to a Data Store
   Inheritance Mapping
   Nested Units of Work
   NULL Value Handling Specifics
   Optimistic Concurrency Control
   Pageable Collections
   Property Descriptors
   Relationships Between Objects
   Saving Persistent Objects
   Simplified Criteria Syntax
   Simplified Property Syntax
   Sorting Basics
   Using Explicit Transactions
   Using Transactions
   Value Converters
   Working with Sessions
   XPCollection Concepts
   XPDataView Concepts
   XPO Classes Comparison
   XPView Concepts
 [Expand]Design-Time Features
 [Expand]Examples
 [Expand]Member Tables
 [Expand]API Reference
[Expand]CodeRush
[Expand]CodeRush Classic
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
 End-User Documentation
View this topic on docs.devexpress.com (Learn more)

Using Transactions

A transaction is a sequential group of manipulation operations, performed as if it were one single work unit. In other words, a transaction will never be complete unless each individual operation within the group is successful. If any operation within the transaction fails, the entire transaction will fail.

Transactions have the following four standard properties (ACID properties).

  • Atomicity: ensures that all operations within the work unit are completed successfully; otherwise, previous operations are rolled back to their former state.
  • Consistency: requires that data bound by a transaction be semantically preserved.
  • Isolation: the result of an individual transaction must be transparent to any other open transaction until that transaction commits successfully.
  • Durability: ensures that the result or effect of a committed transaction persists in case of a system failure.

Within XPO, you can use transactions both at the XPO level (regular transactions) and at a database level (explicit transactions). This document describes ways of working with regular transactions. To learn about explicit transactions, refer to Using Explicit Transactions.

Expanded Managing Transactions

To start a regular transaction, call a session's Session.BeginTransaction method. If a Unit of Work is used, a transaction is started automatically.

Note

Even if you do not start transactions explicitly, XPO automatically starts transactions and commits them to perform persistent object manipulations such as saving or deleting an object. This process does not require your intervention, but still causes all transaction-related events such as Session.FailedCommitTransaction to be raised.

When a successful transaction is completed, a COMMIT command should be issued, so that changes to all involved persistent objects take effect. To do this, call the Session.CommitTransaction method. If a failure occurs, a ROLLBACK command should be issued to return every persistent object in the transaction to its previous state. In this instance, the Session.RollbackTransaction method must be used. It completes the transaction discarding all the changes made since the transaction was started.

Typically these methods are used in code like this:

Since transactions at the XPO level (regular transactions) do not correspond to transactions at a database level (explicit transactions), it is possible to have long-running regular transactions in XPO without promoting concurrency issues in multi-user use cases. It is only when a transaction is committed, that a short database transaction is initiated to apply the changes.

To see if a transaction is in progress, use the Session.InTransaction property.

Expanded Isolation

When a transaction is running and there are uncommitted changes in it - remember that transactions are also the basis of Units of Work and do not correspond to database transactions - a newly constructed XPCollection will not normally be able to "see" the changes that have been made in the current transaction. This is because the collection fetches its content from the database, but the changes have not yet been written there. This is default behavior; we have introduced a flag called PersistentCriteriaEvaluationBehavior that allows you to see a merged state of the data, where changes from the current running transaction are already included.

See the code below. The default collection - which uses the enum value PersistentCriteriaEvaluationBehavior.BeforeTransaction internally - does not see the newly created object, while the collection with the specified behavior PersistentCriteriaEvaluationBehavior.InTransaction finds both the old and new object.

Is this topic helpful?​​​​​​​