Coding System.Transactions Transactions

Coding System.Transactions transactions

To utilize System.Transactions in your solutions, there are two ways to go about the task: by defining them declaratively using attributes or by explicitly defining them in code.

Declarative Coding of Transactions

If you've developed using Enterprise Services in the past, you will already be familiar with adding transactions in a declarative way. Declarative coding for transactions is done by applying attributes.

The following code is an example from an Enterprise Services application. In it you can see that two attributes are assigned, one at the class level and one at the operation level:

[Transaction(TransactionOption.Required)] public class WireTransfer : ServicedComponent {     [AutoComplete]     public double Transfer(int sourceAccountNbr, int targetAccountNbr, double amount);     {         ...     } }

At the class level, the [transaction] attribute is applied. This serves as an instruction indicating that calls to any method within the class will occur within a transactional context.

At the operation level, the [AutoComplete] attribute is placed on the transfer method. This serves as an instruction to automatically commit a transaction if the TRansfer method does not end in error.

Explicit Coding of Transactions

System.Transactions also provides the capability to explicitly code transactions. Transactions will occur within a TRansactionScope. transactionScope provides a definition of the boundaries of the transaction, with all the code contained within it becoming part of the transaction:

using (TransactionScope scope = new TransactionScope ()) {      //Code that will be part of the transaction }

In the preceding code, the transaction is assumed complete when the using statement has been completed. To explicitly state that the scope was completed, use the Complete method on the transactionScope object:

using (TransactionScope scope = new TransactionScope ()) {      //Code that will be part of the transaction      scope.Complete(); }

Transaction scopes can be nested, and when a transactionScope is defined, there is the capability to specify how this scope will work with any ambient transactions. For example, you may want to utilize an ambient transaction, or you may demand that a new transaction be created for a particular scope of workregardless of any existing transactions. You may even want to suppress the ambient transaction context for this scope of work.

You can introduce this when defining your scope, by specifying the appropriate value of the TRansactionScopeOption enumeration. In the following listing, you can see an example in which there are nested transaction scopes and the innermost scope requires that it be part of a new transaction:

[View full width]
using (TransactionScope scope = new TransactionScope (TransactionScopeOption.Required)) {      //Code that will be part of the transaction      using (TransactionScope scope = new TransactionScope (TransactionScopeOption. RequiresNew))      {          //More work that exists inside of a new transaction;      } }

You can also specify additional options, such as isolation level or timeout, by passing in an instance of the TRansactionOptions class to the TRansactionScope constructor. This provides the capability to specify values for things such as isolation level and timeout. The next listing shows the setting of the isolation level of the transaction to ReadCommitted:

[View full width]
public double Transfer(int sourceAccountNbr, int targetAccountNbr, double amount) {         TransactionOptions options = new TransactionOptions();         options.IsolationLevel = IsolationLevel.ReadCommitted;         using (TransactionScope scope = new TransactionScope (TransactionScopeOption. Required, options))         {               //Code that will be part of the transaction         } }