In this article we will discuss about creating transaction enabled WCF service. We will see what needs to be done on the WCF service end so that it support transactions. We will also see how a client application can work with these transaction enabled services using a sample application.
By definition a transaction must be Atomic, Consistent, Isolated and Durable. What does we mean by all these terms
· Atomic: Atomic means that all the statements (SQL statement or operations) that are a part of the transaction should work as atomic operation i.e. either all are successful or all should fail.
· Consistent: This means that in case the atomic transaction success, the database should be in a state that reflect changes. If the transaction fails then database should be exactly like it was when the transaction started.
· Isolated: If more than one transactions are in process then each of these transactions should work independently and should not effect the other transactions.
· Durable: Durability means that once the transaction is committed, the changes should be permanent i.e. these changes will get saved in database and should persist no matter what(like power failure or something).
Now having transactions from a simple class library's perspective ot from a simple .Net applications, it is just a matter of calling the operations within a transaction, checking whether all the operations are successful or not and deciding whether to commit or rollback the transaction. Refer this article to know about transactions in normal application: A Beginner's Tutorial for Understanding Transactions and TransactionScope in ADO.NET[^]
But from a WCF service perspective, since the service itself may be running on a remote server and all the communication between the service and the client is in form of messages, the service itself need some configuration so that it can be made transaction enabled.
Now in rest of the article we will see how we can configure a WCF service to support transactions and how we can call a WCF operation within transactions.
To illustrate the above process, let say I have two account holders, one person is trying to transfer some money to other person. From the database perspective this operation consist of two sub-operations i.e.
· Debiting the first account by specified amount.
· Secondly, crediting the second account with required amount.
Now from a technical perspective, if the first operation is successful but second one fails the result would be that the first persons account will be debited but second one will not be credited i.e. we loose the amount of information. The other way round will in fact increase the amount ion second account without even debiting the first amount.
So the bottom-line here is that we need either both of them to be successful to both of them should fail. Success of any one operation will result in inconsistent results and thus even if one operation fails we need to rollback what we did in the other operation. This is precisely where transaction are useful.
Let us say that the operations for credit and debit are exposed separately from a service. What we need to do is that, we need to transaction enable this service and then call these two methods within a transaction. The transaction will be committed only when both the operation indicate success. In case any one operation indicates failure or throws an exception, the transaction will not be committed.
Let us create a simple service with a ServiceContract that exposes operations to debit an account, credit an account and get the account balance information for any account.
[ServiceContract]
public interface IService1
{
[OperationContract]
bool PerformCreditTransaction(string creditAccountID, double amount);
[OperationContract]
bool PerformDebitTransaction(string debitAccountID, double amount);
[OperationContract]
decimal GetAccountDetails(int id);
}
Now we want the operations PerformCreditTransaction and PerformDebitTransaction to work within a transaction. To do this we need to make some configuration in the service. The very first thing that is required with the OperationContract is to set the TransactionFlow property with the desired TransactionFlowOption. There are 3 possible values for TransactionFlowOption:
· Mandatory: This specifies that this function can only be called within a transaction.
· Allowed: This specifies that this operation can be called within a transaction but its not mandatory.
· NotAllowed: This specifies that this operation can not be called within a transaction.
Now for both our operations, we want the operations to be called mandatory within a transaction so we will specify them with this option.
[ServiceContract]
public interface IService1
{
[OperationContract, TransactionFlow(TransactionFlowOption.Mandatory)]
bool PerformCreditTransaction(string creditAccountID, double amount);
[OperationContract, TransactionFlow(TransactionFlowOption.Mandatory)]
bool PerformDebitTransaction(string debitAccountID, double amount);
[OperationContract]
decimal GetAccountDetails(int id);
}
Now to illustrate the implementation part,
We will work on a small application that contains a single table database. This table contains the account id and the amount present in the account.
The sample DB table looks like:
The UI will look like:
And now to perform these operations, we will write simple ADO.NET code in our service implementation. The important thing from the service implementation perspective is that the service implementation also needs to be decorated/adorned with OperationBehavior attribute with TransactionScopeRequired property set to true. So now let us look at the sample implementation of the service operations.
public class Service1 : IService1
{
readonly string CONNECTION_STRING = ConfigurationManager.ConnectionStrings["SampleDbConnectionString1"].ConnectionString;
[OperationBehavior(TransactionScopeRequired = true)]
public bool PerformCreditTransaction(string creditAccountID, double amount)
{
bool creditResult = false;
try
{
using (SqlConnection con = new SqlConnection(CONNECTION_STRING))
{
con.Open();
using (SqlCommand cmd = con.CreateCommand())
{
cmd.CommandType = CommandType.Text;
cmd.CommandText = string.Format(
"update Account set Amount = Amount + {0} where ID = {1}",
amount, creditAccountID);
creditResult = cmd.ExecuteNonQuery() == 1;
}
}
}
catch
{
throw new FaultException("Something went wring during credit");
}
return creditResult;
}
[OperationBehavior(TransactionScopeRequired = true)]
public bool PerformDebitTransaction(string debitAccountID, double amount)
{
bool debitResult = false;
try
{
using (SqlConnection con = new SqlConnection(CONNECTION_STRING))
{
con.Open();
using (SqlCommand cmd = con.CreateCommand())
{
cmd.CommandType = CommandType.Text;
cmd.CommandText = string.Format(
"update Account set Amount = Amount - {0} where ID = {1}",
amount, debitAccountID);
debitResult = cmd.ExecuteNonQuery() == 1;
}
}
}
catch
{
throw new FaultException("Something went wring during debit");
}
return debitResult;
}
public decimal GetAccountDetails(int id)
{
decimal? result = null;
using (SqlConnection con = new SqlConnection(CONNECTION_STRING))
{
using (SqlCommand cmd = con.CreateCommand())
{
cmd.CommandType = CommandType.Text;
cmd.CommandText = string.Format("select Amount from Account where ID = {0}", id);
try
{
con.Open();
result = cmd.ExecuteScalar() as decimal?;
}
catch (Exception ex)
{
throw new FaultException(ex.Message);
}
}
}
if (result.HasValue)
{
return result.Value;
}
else
{
throw new FaultException("Unable to retrieve the amount");
}
}
}
Note: The code is written to elaborate the transaction enabled services only, it is not as per the coding standards i.e it is vulnerable to SQL injection. It should not be taken as code that could go in production. It is just the sample code and has a lot of scope for improvement.
Now we have our ServiceContract ready and service implementation ready. Let us now use the appropriate binding i.e. wsHttpBinding to use this service. Also, in the service configuration we need to specify that this service is transaction enabled. This can be done by setting the transactionFlow property of the binding configuration ofwsHttpBiding to true
Note: Please refer the web.config of the sample code to see how this is done.
From our test application, we will simply call the functions within a transaction(using TransactionScope). We will check both the operations' return value, if both of the indicates success, we will commit the transaction(by calling Complete method on TransactionScope object). If any operation fails we will rollback the transaction by not calling Complete function and simply letting the TransactionScope object go out of scope).
private void PerformTransaction(string creditAccountID, string debitAccountID, double amount)
{
bool debitResult = false;
bool creditResult = false;
try
{
using (TransactionScope ts = new TransactionScope())
{
using (ServiceReference1.Service1Client client = new ServiceReference1.Service1Client())
{
debitResult = client.PerformDebitTransaction(debitAccountID, amount);
creditResult = client.PerformCreditTransaction(creditAccountID, amount);
}
if (debitResult && creditResult)
{
ts.Complete();
}
}
}
catch
{
}
}
The code currently will work fine i.e. both the methods will return true and the transaction will get committed. To check the rollback action, we have a simple return false; statement commented in our service'sPerformCreditTransaction operation, un-comment this statement to check that the transaction will not get committed.
Note: The code snippets shows the relevant code in the context. Please look at the sample code to get the full understanding.
So now we have a service that supports transactions. Before wrapping up let is look at the main operations we need in order to make a service transaction enabled.
1. Decorate the OperationContract with required TransactionFlowOption.
2. Decorate the operation implementation with OperationBehavior with TransactionScopeRequired as true.
3. Use wsHttpBinding to utilize the underlying WS-AtomicTransaction protocol.
4. Specify the transactionFlow property of the binding configuration of wsHttpBinding as true.
