A very important issue you must tackle when designing a business layer is how you plan to manage transactions. Many business methods call multiple DAL methods internally to update, insert, or delete multiple records, potentially in multiple tables. You must ensure that multiple calls run within a transaction, so that if one fails, all actions performed by previous methods are rolled back. If you don’t do this, you’ll end up having inconsistent, and wrong, data. Managing transactions would be complicated if you had to do everything yourself, but fortunately there are several technologies and frameworks that can do the plumbing for you.

ADO.NET Transactions

In the simplest case you can use explicit ADO.NET client-side transactions. You should already be familiar with them, but here’s some sample code that runs a couple of commands inside a transaction to refresh your memory:

using (SqlConnection cn = new SqlConnection(connString))

{

   cn.Open();

   SqlTransaction tran = cn.BeginTransaction();

  

   try

   {

      SqlCommand cmd1 = new SqlCommand(cmdText1, cn, tran);

      cmd1.ExecuteNonQuery();

 

      SqlCommand cmd2 = new SqlCommand(cmdText2, cn, tran);

      cmd2.ExecuteNonQuery();

 

      tran.Commit();

   }

   catch(Exception e)

   {

      tran.Rollback();

   }

}   

The preceding code is simple and works fine in many situations. However, the transactions managed by ADO.NET are connection-bound, which implies the following limitations:

• You have to use them from the DAL, where you have the connection objects, and not from the BLL where you’ll typically (but not necessarily) want to manage transactions. This is not a problem if you’re employing a lighter architecture with the DAL and BLL mixed together in a single layer, which may actually be a valid choice for small sites, but it does pose a problem for multi-tier systems.
• The transaction is bound to a single connection, which means it can’t span multiple databases. This may be required if, for example, you store all data for the forums module in one database and the articles data on some other database, and you need some business method that updates some records in both systems within one logical transaction.
• All commands you execute must use the same connection. If these commands are executed from different methods, wrapping them into a single transaction means that you must find some way to pass the connection object through all the methods. This could be done with an additional method parameter, but this leads to an ugly and inflexible design.

COM+ and SWC Transactions

All of the problems presented can be solved by using COM+ as the application server for your components. COM+ can handle transactions that include multiple commands and multiple connections (also to different data stores), and generally any action that the DTC (Distributed Transaction Coordinator) can manage, such as sending a MSMQ message. By using COM+ you can easily write atomic and isolated procedures; once you start the transaction in a method, you can have all submethods enlist into the transaction automatically, and have the transaction be committed if no exception is thrown or otherwise rolled back. If your class inherits from System.EnterpriseServices.ServicedComponent, the transaction handling is configurable by means of .NET attributes (e.g., AutoCompleteAttribute, for the automatic transaction completion just outlined) that you apply at the assembly, class, and method level. Here’s a sample transactional class that uses attributes to configure automatic transactions:

[Transaction(TransactionOption.RequiresNew)]

public class SampleBO : ServicedComponent

{

   [AutoComplete]

   public void UpdateDate()

   {

      MyBizObject1 obj1 = new MyBizObject1();

      obj1.DoSomething();

 

      MyBizObject2 obj2 = new MyBizObject2();

      obj2.DoSomethingElse();

   }

}

If you don’t like declarative transactions, you can still handle them imperatively in code through the ContextUtil helper class, and its EnableCommit, DisableCommit, SetAbout, and SetComplete methods.

COM+ transactions add a lot of overhead to simple ADO.NET transactions, and as a result they are much slower (even 50%). However, COM+ doesn’t just mean transactions, but also object polling, just-in-time activation, queued components and much more—all features that can make your application more reliable and scalable, which is often more important than plain performance statistics. And, after all, if your application shuts down after a high load, how useful is it to know that it was extremely fast with a few users, when it was started? The problem with using COM+ in .NET is that your business objects must inherit from System.EnterpriseServices.ServicedComponents and must respect a number of rules (for example, you can’t define static methods), and you must make this decision early on; otherwise, adding transaction support later will require a lot of additional work. Another problem is that deploying .NET Enterprise Services is not as easy as deploying a normal assembly, as you must generate a COM type library from the assembly, and register it into the Windows registry and the COM+ catalog. These are operations that only a system administrator for the remote server can do, so you won’t be able to do this if you’re planning to deploy your site using an inexpensive shared hosting provider service.

Fortunately, though, if you’re hosting the site on Windows Server 2003, you can take advantage of a new feature of COM+ 1.5 called Services Without Components (SWC). This should also work on Windows XP, but you should never deploy a production web application to a client version of Windows for performance and reliability reasons. This feature allows you to configure, start, and manage a distributed transaction without actually writing a typical COM+ component that must be registered in the COM+ catalog. With the .NET Framework 1.1, you can do everything with the ServiceConfig, ServiceDomain, and ContextUtil classes that you find in the System.EnterpriseServices.dll assembly, under the System.EnterpriseServices namespace. You can configure the transaction on-the-fly by creating an instance of ServiceConfig and setting the transaction type (Transaction and IsolationLevel properties), specifying whether tracking is enabled (TrackingEnabled property), the application and component name (TrackingAppName and TrackingComponentName properties), and other options. Finally, you start the transaction by calling the Enter static method of the ServiceDomain class, which takes the ServiceConfig object that specifies the configuration. You use the SetComplete and SetAbort static methods of the ContextUtil class to commit or roll back the transaction, respectively. Here’s an example:

// configure and start the transaction

ServiceConfig svcConfig = new ServiceConfig();

svcConfig.TrackingEnabled = true;

svcConfig.TrackingAppName = "TheBeerHouse";

svcConfig.TrackingComponentName = "MB.TheBeerHouse.BLL.SampleBO";

svcConfig.Transaction = TransactionOption.RequiresNew;

svcConfig.IsolationLevel = TransactionIsolationLevel.ReadCommitted;

ServiceDomain.Enter(svcConfig);

 

try

{

   MyBizObject1 obj1 = new MyBizObject1();

   obj1.DoSomething();

 

   MyBizObject2 obj2 = new MyBizObject2();

   obj2.DoSomethingElse();

 

   ContextUtil.SetComplete();

}

catch (Exception e)

{

   // rollback the transaction

   ContextUtil.SetAbort();

}

finally

{

   ServiceDomain.Leave();

}

This code wraps the calls to two different business objects into a single distributed transaction controlled by the DTC. You only have to start the transaction, catch exceptions that may be thrown, and commit or roll back the transaction. You don’t have any special deployment needs: a simple XCopy is enough. Also, SWC is good because you can easily add transactions to business objects that weren’t originally designed to handle distributed transactions—namely, objects that don’t inherit from ServicedComponent, and that call DAL methods that are not ADO.NET transaction-aware (that don’t pass Transaction objects as parameters). SWC, however, doesn’t completely replace traditional Enterprise Services components, as they don’t allow you to use other features such as object pooling, just-in-time activation, queued components, and all other COM+ functionality; you can use them just to add transaction support with the least development and deployment effort. All in all, this is a very welcome facility that should be used thoughtfully.

The new System.Transactions Namespace

SWC transactions are definitely good, but the version 2.0 of the .NET Framework introduces something even better: a new System.Transactions namespace which provides a modern, managed interface to handle transactions that can not be handled by ADO.NET’s SqlTransaction class! Two new transaction managers were introduced: Lightweight Transaction Manager and OleTx Transaction Manager. The former manages transaction bound to a single durable resource (i.e. a single connection to a single data store), while the latter can manage distributed transaction, where multiple connections to different data stores come into play. You don’t have to choose between the two yourself; a proper transaction manager will be automatically chosen according to the type and the number of resources that you wish to use into a transaction scope.

The basic class that you’ll be using is System.Transactions.TransactionScope. When an object of this type is created, it starts a lightweight transaction. Then you start creating your connections and other transaction-aware resources (such as MSMQ queues and messages). As long as you use a single resource that supports lightweight transactions, the transaction will be handled by the resource manager itself. SQL Server 2005 (including the Express Edition) has this capability, so if you create a single connection to one of its databases, it will take care of everything internally, consuming as little resources as possible, and with very good performance. As soon as you introduce a second connection/resource into the transaction scope however, the transaction manager will automatically be promoted to a OleTx Transaction Manager, which is able to handle distributed transactions by means of the COM+ DTC technology under the covers (it dynamically configures a temporary Enterprise Service through SWC). This also happens if you have a single connection to a resource manager which doesn’t support lightweight transactions, such as SQL Server 7/2000, Oracle, and other RDBMSs.
Here’s an example that starts a transaction and runs a couple of different commands within it:

using(TransactionScope scope = new TransactionScope())

{

   using (SqlConnection cn = new SqlConnection(connString))

   {

      cn.Open();

      SqlCommand cmd1 = new SqlCommand(cmdText1, cn);

      cmd1.ExecuteNonQuery();

 

      SqlCommand cmd2 = new SqlCommand(cmdText2, cn);

      cmd2.ExecuteNonQuery();

   }

   scope.Complete();

}

Since the two commands share the same connection, a lightweight transaction will be created if connString points to a SQL Server 2005 database. As I mentioned before though, transactions are often run from the BLL, and must wrap calls to several other methods, which internally may create separate connections and target different databases. The code is still as simple as the code above, though:

using(TransactionScope scope = new TransactionScope())

{

  MyBizObject1 obj1 = new MyBizObject1();

   obj1.DoSomething();

 

  MyBizObject2 obj2 = new MyBizObject2();

   obj2.DoSomethingElse();

 

   scope.Complete();

}

When this code is run, a distributed COM+ transaction will probably be created under the covers (it depends on whether the two methods use two connections, or share a single one), but the developer doesn’t need to know this, and doesn’t have to do anything special at designtime or deployment time. Another advantage of using System.Transactions is that you can create transactions only in methods where you really need them, and you don’t have to make a whole class transactional. Given how simple it is to work with TransactionScope and related classes, you don’t even need to build a framework or some sort to base service to simplify things, it’s all already there! However, I would not recommend COM+, SWC or System.Transactions for use with shared web hosting because the servers are out of your control and it’s not clear whether this could be used reliably in an environment where server reconfiguration is commonplace. Also, in the sample website for this book we won’t make use of these advanced technologies.

If you want to know more about System.Transactions, refer to Juval Lowy’s whitepaper entitled “Introducing System.Transactions in the Microsoft .NET Framework version 2.0”, downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyId=AAC3D722-444C-4E27-8B2E-C6157ED16B15&displaylang=en

---

NOTE: This excerpt was taken from the book "ASP.NET 2.0 Website Programming". Click here to find more about it, and download the complete source code of the sample project.