Browse DevX
Sign up for e-mail newsletters from DevX


Control Transaction Boundaries Between Layers

A connection broker enables your business layer to control transaction boundaries in a compact and efficient way. Learn how to roll your own broker to centralize and manage your application code's access to database resources.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

hen developing a software solution on a three-layered architecture, an inevitable mismatch emerges between business transactions and system transactions. Business transactions stem from application requirements, and they are defined at the application/business layer, while system transactions (e.g., database transactions) are tied to a specific technology (SQL Server, MSMQ, etc.). No technology defines a business transaction; it's just a description of a business process, which either fails or succeeds as a whole. This description is typically provided with domain-specific terminology and is best expressed in terms of object collaboration.

Since the layer where business transactions conceptually live has no direct access to the database, system transactions do not naturally map to business transactions.

In fact, the three-layered architecture requires you to encapsulate data-access code into a data layer to remove the database-access details from the business layer. You then use object-relational mapping routines (unless you use DataSets) on the border of the two layers to move data back and forth between the database and business objects.

Object-relation mapping routines undoubtedly make things easier by providing a bridge between objects and the database. However, they do not provide a robust, transparent way to define and control transactional boundaries at the business layer way (it's just not their responsibility). If you do not anticipate this problem during your application design, your nice layered architecture will break once transactional requirements pop up. For instance, connection and database-related details (MSMQ details and so on) creep from the data layer into the business layer, typically as when connection and transaction ADO/ADO.NET objects are passed around the business entities (an error-prone practice).

A naïve, yet typical solution to the problem is hard-coding the dependency order among objects at design time. This is a bad idea for all but the simplest applications, because object collaboration paths vary across different application tasks. An object can be the root of a business transaction in one situation and a child in another depending on the day. Whenever it switches, you'll have to chase down all the hard-coded assumptions in your code.

For these reasons, one of the main concerns application architects have is assuring ahead of time a robust, manageable framework for applications to map database transactions to business transactions. This way, each business object can focus on its tasks, committing and "rollbacking" its own job, oblivious to its transactional context.

The COM+ Option
A powerful, yet easy way to define transactions at the business-layer level is using COM+ declarative transactions. You just flag your business objects with the proper transactional requirements and the COM+/DTC infrastructure enlists database (and eventually MSMQ) connections into a single unit of work transparently. So you don't have to coordinate the work of the data layer; each data layer component opens its own connection and fires data changes to the database. The DTC will commit or rollback the business transaction as a whole at the application layer.

This approach has its benefits and liabilities. The benefits include:

  • It lets you compose business components into transactional units easily. You can plug new components into the business transaction without intervening into the existing ones.
  • DTC-based transactions can spawn across process and machine boundaries.
  • DTC-based transactions can handle work distributed to more than one database server as a single transaction.
The liabilities include the following:
  • DTC-based transactions impose a performance overhead into the data access layer, about 30-40 percent on average. This is due to the fact that they have been designed to handle transactions across different databases (more exactly, across different resource managers).
I've personally used the COM+ approach often while working with VB6 in the pre-.NET era. I gave up some performance to gain more flexibility in my application design, even when no distributed databases were involved.

Thanks to .NET, you can now easily design a small framework that the data-access layer uses to accommodate transparent management of database transactions—without involving the DTC. This way, you can keep your focus on the business transaction scope, without incurring the overhead that COM+ transactions impose.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date