Is it possible to exchange a transaction between a .Net application and a COM + object?

Question

A few years ago I did some tests and never figured out how to do this.

Ingredients:

• COM + transactional object (developed in VB6)
• An .Net application (with transaction) in IIS that ... makes a call to the COM + component
  updates a row in a SQL database

Testing:

Run the .Net application and throw an exception.

Result:

Update made from .Net application, rollback.
An update made by a COM + object does not roll back.

If I call the COM + object from the old ASP page, the rollback works.

I know that some people might think “what ?! COM + and .Net you should be out of your mind!”, But in this world there are places where there are still many COM + components. I was just curious if anyone came across this, and if you figured out how to make this work.

Answer 1

Since VB and .NET will use different SQL connections (and there is no way to make ADO and ADO.NET the same connection), your only option is to enlist the DTC (Distributed Transaction Coordinator). DTC will coordinate two independent transactions so that they complete or collapse together.

From .NET, EnterpriseServices manages COM + features such as DTC. In .NET 2.0 and forward, you can use the System.Transactions namespace, which makes things a little nicer. I think something like this should work (unverified code):

void SomeMethod() { EnterpriseServicesInteropOption e = EnterpriseServicesInteropOption.Full; using (TransactionScope s = new TransactionScope(e)) { MyComPlusClass o = new MyComPlusClass(); o.SomeTransactionalMethod(); } } 

I am not familiar enough with this to give you more advice at the moment.

On the COM + side, your object must be configured to use (most likely "required") a distributed transaction. You can do this from COM + Explorer by going to your Properties object, selecting the Transaction tab, and clicking Mandatory. I don’t remember if you can do this from code; VB6 was created before the release of COM +, so it does not fully support everything that COM + does (its transactional support is for the predecessor of COM +, called MS Transaction Server).

If everything works correctly, your COM + object must be credited to the existing Context created by your .NET code.

You can use the "Distributed Transaction Coordinator \ Transaction List" node in "Component Services" to check and view the distributed transaction that is created during the call.

Keep in mind that you do not see changes from the COM + component reflected in the data requests from the .NET side until the transaction is completed! In fact, you can come to a standstill! Remember that DTC will verify that two transactions are conjugated, but they are still separate database transactions.

Answer 2

How do you implement this? If you use EnterpriseServices to manage a .NET transaction, then both transactions must be rollback, because you use the same context for them.