Transaction Scope - Hopes dashed

Recently we have implemented Transaction scope within our solutions, as the perceived benefits were many.

• An external process is not used to execute the assembly


• Nothing needs to be registered beyond adding to the GAC


• Objects do not need to be marshaled across the COM boundary


• Transactions control is much finer


• MSDTC calls are only made when they are required

These factors combined would have a significant impact on the speed of our build, test and release processes.

Initial tests were very positive not only were the build, test and release processes improved but there were also noticeable performance improvements.

A planned release was built and passed in QA for testing. During QA of our invoicing process we started getting transaction scope errors. Investigation into these errors showed that our data layer architecture which involved tiered data mappers creating and closing their own database connections was the root cause. I.e. when the datamapper closed its database connection it caused the transaction within which it was running to close. Investigation into this via Google (other search engines are available ^^) produced some rather telling results, the most informative being;
MSDN Forum
My reading of this is that

• Microsoft recognize this as an limitation within Visual Studio 2005 & Transaction scope


• resolution of this issue would involve changes to the client, server and the client-server protocol


• This change is not going to be happening any time soon!

So having read all this we are now in the process of rolling back our changes to pre Transaction scope changes, though we are investigating a change to our datalayer to pass around the database connection as suggested in the final post.

To be continued...