In my previous post, I discussed the use of
TransactionScope within C# and how it might simplify how transactions are managed within your applications. It covered what transactions are, some of the ways that they are traditionally managed, and how the use of
TransactionScope could clean up your code and let "magic" take care of the rest. But as well all know - even the best magicians screw up occasionally.
This post discusses some of the common issues and caveats that you might run into when using the feature, how to overcome some of them, and when you might have to simply bite the bullet and avoid it altogether.
Some Common Caveats/Issues
I'll expand on each of these below, but a few things to look out for when using
- Handling Multiple Connections Across Different Databases - This will involve the Microsoft Distributed Transaction Coordinator Service, which could complicate things/make them impossible.
- Handling Asynchronous (e.g. async/await) - Since the underlying ambient transaction is static, multi-threaded environments will complicate things.
- Timeout-related Errors - Ensuring you have appropriate timeouts set can be a challenge if you start running into errors, as the defaults are ... strange.
Player MSDTC has Entered the Game
Sharing transactions between connections with the same server and/or database is pretty trivial, however if you start querying multiple different sources/databases within a single transaction, you'll quickly be introduced to a new friend named the Microsoft Distributed Transaction Coordinator service, which does the following in a nutshell:
The MSDTC is a Windows service providing transaction infrastructure for distributed systems. In this case, a transaction means a general way of structuring the interactions between autonomous agents in a distributed system. Each transaction is a state transformation with four key properties - the ACID properties: Atomic (all or nothing), Consistent (legal), Isolated (independent of concurrent transactions) and Durable (once it happens, it cannot be abrogated). There are different techniques that implement the ACID properties but the most known one is two-phase commit.
Transactions contained within a TransactionScope are automatically promoted to "Distributed Transactions" as soon as multiple databases are involved and thus any servers must the MSDTC service enabled in order to operate as expected. This is extremely important as the calls will simply fail if the service is not enabled (and you won't always get the best error messages in the world to troubleshoot this).
If you are in total control of your environments, this might not be an issue. However, if your product is deployed on-prem, or if you have queries that rely on
OPENQUERY or target Linked Servers, which you might not own, you may not be able to guarantee that the service is enabled.
In a world of SPAs, promises, and parallelism, applications deal with asynchrony much more commonly than in the years of old. The advent of things like
async/await made this process much easier, but if you are dealing with transactions, there are quite a few things that you should be aware of.
In a nutshell, async/await doesn't work well within a TransactionScope block out of the box and requires some additional configuration to tell it how to resolve the operations via an
TransactionScopeAsyncFlowOption, which might look something like this:
using (var transaction = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
Another important consideration is that the ambient transaction that is discussed in the previous post to back the transactions is thread-static and thus won't work as expected in multi-threaded environments. As always - use your best judgement to determine to group a series of transactions together, and if there is a better fit given your environment.
Managing timeouts is vital when working with transactions as there are a bevy of issues that could arise if you shoot too high or shoot too low. Extremely long timeouts can lead to issues with blocking/deadlocks, which are a nightmare to troubleshoot, and those that err on the side of being too short might not get the job done.
If the following error message looks familiar, then you might be in a situation where you need to reassess your existing timeouts:
The transaction associated with the current connection has completed but has not been disposed. The transaction must be disposed before the connection can be used to execute SQL statements.
Depending on your situation, you might use something like this and call it a day:
using (var transaction = new TransactionScope
Absolutely don't do this. This will almost certainly lead to blocking/deadlocks that will drive you crazy and this actually won't even work as expected. In most situations, you'll receive the previous error and that's because any explicit timeout values for a TransactionScope will always be limited by the
maxTimeout option likely found within your application's config:
<machineSettings maxTimeout="01:00:00" />
maxTimeout is 10 minutes, so if you begin encountering timeout issues, you'll want to find a happy medium for this setting between that default and some upper-bound. Use your best judgement err towards a shorter timeout any potential deadlock/blocking issues arising.
An experienced Software Developer and Graphic Designer with an extensive knowledge of object-oriented programming, software architecture, design methodologies and database design principles. Specializing in Microsoft Technologies and focused on leveraging a strong technical background and a creative skill-set to create meaningful and successful applications.
Well versed in all aspects of the software development life-cycle and passionate about embracing emerging development technologies and standards, building intuitive interfaces and providing clean, maintainable solutions for even the most complex of problems.