TRANSACTIONS IN WCF

The TransactionIsolationLevel property determines how the database management system (SQL Server in the
exercises in this book) lets concurrent transactions overlap. In a typical system, multiple concurrent users access the
database at the same time. However, this can lead to problems when two users try to modify the same data at the
same time, or when one user tries to query data that another user is modifying. You must ensure that concurrent
users cannot interfere adversely with each other—they
must be isolated. Typically, whenever a user modifies, inserts, or deletes data during a transaction, the database
management system locks the affected data until the transaction completes. If the transaction commits, the database
management system makes the changes permanent. If an error occurs and the transaction rolls back, the database
management system cancels the changes. The TransactionIsolationLevel property specifies how the locks applied
during a data-modification transaction affect other transactions attempting to access the same data.
TheTransactionIsolationLevel property can take one of several values. The most common isolation levels are:
❏❏ IsolationLevel.ReadUncommitted This isolation level enables the transaction to read data that another
transaction has modified and locked, but not yet committed. This isolation level provides the most concurrency;
however, there is the risk of the user being presented with “dirty” data that might change unexpectedly if the
modifying transaction rolls back the changes rather than committing them.
❏❏ IsolationLevel.ReadCommitted This isolation level prevents the transaction from reading data that another
transaction has modified, but not yet committed. The reading transaction will be forced to wait until the modified
data is unlocked. Although this isolation level prevents read access to dirty data, it does not guarantee consistency; if
the transaction reads the same data twice, there is the possibility that another transaction might have modified the
data in between reads, thus the reading transaction would be presented with two different versions of the data.
❏❏ IsolationLevel.RepeatableRead This isolation level is similar to the ReadCommitted isolation level, but it causes
the transaction reading the data to lock this data until the reading transaction finishes (the ReadCommitted isolation
level does not cause a transaction to lock data that it reads). The transaction can then safely read the same data as
many times as it wants without the data being changed by another
transaction until this transaction has completed. This isolation level therefore provides more consistency, at the cost
of reduced concurrency.
❏❏ IsolationLevel.Serializable This isolation level takes the RepeatableRead isolation level one stage further. When
using the RepeatableRead isolation level, data read by a transaction cannot change. However, it is possible for a
transaction to execute the same query twice and obtain different results if another transaction inserts data that
matches the query criteria: new rows suddenly appear. The Serializable isolation level prevents this inconsistency
from occurring by restricting the rows that other concurrent transactions can add to the database. This isolation level
provides the greatest level of consistency, but the degree of concurrency can be significantly reduced.
Unless you have a good reason to choose otherwise, use the IsolationLevel.Repeatable
Read isolation level.

Changes to implement Transactions in WCF:

Locate the Service Behavior attribute that precedes the ServiceImpl class. Add the following
TransactionIsolationLevel property (shown in bold) to this attribute:
[Service Behavior (InstanceContextMode = InstanceContextMode.PerSession,
TransactionIsolationLevel=IsolationLevel.RepeatableRead)]
public class ShoppingCartServiceImpl : IShoppingCartService
{
...
}

In the ShoppingCartServiceImpl class, add the following OperationBehavior attribute to the AddItemToCart
method:
[OperationBehavior(TransactionScopeRequired=true, transactionAutoComplete=false)]
public bool AddItemToCart(string productNumber)
{
...
}

TransactionScopeRequired property : of the OperationBehavior attribute to true forces the operation to execute
as part of a transaction; either the client application must initiate the transaction (you will see how to do this
shortly) or the WCF runtime will automatically create a new transaction when this operation runs.
The TransactionAutoComplete property specifies what happens to the transaction when the operation finishes. If
you set this property to true, the transaction automatically commits and makes all its changes permanent. Setting
this property to false keeps the transaction active; the changes are not committed yet. The default value for this
property is true. In the case of the AddItemToCart method, you don’t want to commit changes and finish the
transaction until the user has checked out and paid for the
goods, so the code sets this property to false.

Add the TransactionFlow attributes (shown in bold in the following code) to all the method definitions
in the IShoppingCartService interface, just after the OperationContract attribute:

public interface IShoppingCartInterface

Specifying a parameter of TransactionFlowOption.Mandatory indicates that the client application must create a
transaction before calling this operation and must send the details of this transaction as part of the SOAP message
header when invoking the operation. The other values you can specify are TransactionFlowOption.Allowed,
which will use a transaction created by the client if one exists (the WCF runtime will create a new transaction if
not), and TransactionFlowOption.NotAllowed, which causes the WCF runtime to disregard any client transaction
and always create a new one.
The default value is TransactionFlowOption.NotAllowed.

Note Not all bindings allow you to flow transactions from client applications into a service. The
bindings that do not support transactions include BasicHttpBinding, NetMsmqBinding, NetPeer
,TcpBinding, and WebHttpBinding.