K2 [blackpearl] Transactional Model

Being inspired by K2.NET 2003 documentation (see KB000066 for more details) and led by a direct experience I decided to put down this post about the transactional model that lies behind K2 [blackpearl].

Transaction Processing

When you purchase an item from an online store, you exchange money (in the form of credit) for the item. If your credit is good, a series of related operations ensures that you get the item and the store gets your money. However, if a single operation in the series fails during the exchange, the entire exchange fails. You do not get the item and the store does not get your money.

The technology responsible for making the exchange balanced and predictable is called transaction processing. Transactions ensure that data-oriented resources are not permanently updated unless all operations within the transactional unit complete successfully. By combining a set of related operations into a unit that either completely succeeds or completely fails, you can simplify error recovery and make your application more reliable.
A transaction is a set of related tasks that either succeed or fail as a unit. In transaction processing terminology, the transaction either commits or aborts. For a transaction to commit, all participants must guarantee that any change to data will be permanent. Changes must persist despite system crashes or other unforeseen events. If even a single participant fails to make this guarantee, the entire transaction fails. All changes to data within the scope of the transaction are rolled back to a specific set point.

Automatic transaction processing is a service provided by COM+ that enables you to configure a class at design time to participate in a transaction at run time. To use this service, the class must derive directly or indirectly from the System.EnterpriseServices.ServicedComponent class.

Writing Serviced Components

A serviced component is the mechanism that enables COM+ services to be available to .NET Framework classes. You can modify any Common Language Specification (CLS)–compliant class to use COM+ services. The System.EnterpriseServices namespace provides custom attributes and classes for accessing these services from managed code.
If you are new to writing serviced components take a look here.
If you are new to transaction isolation level in COM+ take a look here.

Enable Root Transactions in K2 [blackpearl] Server Events

In order to make a K2 Server Event working in a transactional manner you need to configure this behaviour both at the Activity and Event level. It is as simple as checking two check boxes in the General Properties Wizard for the Activity and one of the contained Server Events:

There is only a rule to bear in mind: a transactional Activity can contain only a single Server Event marked as transactional. This basically means that the transaction context does not flow across different Server Events within the same Activity. Missing this requirement may result in unexpected behaviour (like the process halting in running state indefinitely).
What happens behind is that K2 [blackpearl] registers on the fly a transactional serviced component (K2STXH). This component is used this component as the root of the transaction when executing via reflection the code contained within the transactional Server Event.
The aforementioned K2 transactional server component presents the following characteristics:

• TransactionOption is RequiredNew: it means that a new transaction is created (the component is the root of the transaction)


• IsolationLevel is ReadCommitted

Writing Serviced Components for K2 [blackpearl]

You can write transactional serviced components and enlist them in a transaction originated from the K2 Server Event.
In order to allow your serviced components to be enlisted in a transaction started from a K2 [blackpearl] Server Event you have to:

• Configure the TransactionOption as Required or, at least, Supported. This is because the serviced component that K2 uses as the root of the transaction has its transaction option configured as RequiredNew.Marking your serviced components as RequiredNew will generate a new transaction while marking them as NotSupported will make them not to take part to the transaction


• You cannot configure them with a transaction isolation level higher than ReadCommitted. This is because the serviced component that K2 uses as the root of the transaction has its isolation level configured as ReadCommitted