A week ago I started working on a new project for
PAG, this new project is a reference document and implementation for an application architecture, it's a very interesting project.... of course I can't talk too much about it here ;). One of the first tasks I was given is researching many different ways to implement COM+ transactions for .Net. code
Of course using COM+ which is very interesting and widely used technology, it's also nd a set of component services totally based in interception. In COM+
aspects are widely used (there's a lot of articles and blogs about this
here,
here, and
here ).
One of the most ugly features of COM+ is that in order to use transactions you must declare a component as "transactional", for example if the component
Customer had a method
Save and the component
Order aslo had a method
Save, in order to define an ACID transaction that calls
customer.Save and
order.Save, both operations within the same transaction, you must declare the component
Customer and
Order as "transactional". Of course this brings a lot of performance troubles if your Customer component also had, for example, a method
SelectAll, because the transaction will lock every record selected until the transaction gets Committed or Rollbacked (Aborted in COM+ terms). The problem is that "transactionability" is an
aspect for the execution context, it does not belongs to the
Customer or
Order components.
There are some solutions for this problem but many of them changes the way you have to code or develop your components.
In COM+ 1.5 (W2K3 and WXP) there's an unpopular feature which is named "COM+ Services without Components", explained in this
MSDN article and
here is the MSDN documentation, it's a COM component that allows creating a COM+ context (with the desired context feature) without using a COM component to initialize the context. The programming model allows to call a method to create a context, after the method is called, every operation issued over a transactional resource will be included in the transaction until another method is called to leave the context.
Using .NET 1.0 you can define the Interop classes or using Managed Extensions a wrapper can be created so those features can be used in a managed environment. In .NET 1.1 a class called
ServiceDomain was included as a wrapper for that feature.
The following code demonstrates how to use it:
// (A) perform any operation on any transactional resource
ServiceConfig svcc = new ServiceConfig();
svcc.Transaction = TransactionOption.Required;
ServiceDomain.Enter( svcc );
// (B) perform any operation on any transactional resource
ContextUtil.SetAbort(); //SetCommit();
ServiceDomain.Leave();
// (C) perform any operation on any transactional resource
After the execution you will notice that operation performed on A and C have been committed, but the operation performed on operation B does not. It's a great feature you can use in .NET.
Some limitations In MSDN says it's only supported on Windows 2003, in Windows XP there's a version of COM+ 1.5 but some people says it's broken.... i run a very simple code and it worked fine.... i really don't have field experience about it's behavior in WinXP. It CAN'T be used on Windows 2000.
There's also a cool feature in COM+ 1.0 called BYOT i was using, and i'm really impressed about it. This allows passing transactions between proceses... and a very simple solutions about how to marshal transactions using Remoting. I'll blog about BYOT in a couple of days.
If you may have some questions you can take a look at the EnterpriseServices FAQ in GDN.