That pesky "D"

A transaction manager doesn't actually provide the ACID attributes of a transaction.  That true of all transaction management services.  Even so, I have seen a number of questions about the volatile resource manager support in System.Transactions.  The big concern is that a volatile transaction doesn't provide the “D” (durability).

I would disagree.  I believe it does, and want to use a couple of thought experiments to help describe how.  First, let's assume I have a “normal” transaction involving a database -- let's assume it is a traditional MSDTC-based transaction.  Does that provide the “D”?  I think the normal answer would be “yes”, and if probed, most people that I've talked to would say that it is because the transaction outcome was logged.

Now let's say that this system is changed so that every 3rd time I reboot the transaction manager automatically resets its log.  Does that provide “D”?  Even though it still logs the outcome, I would say probably not -- because I have no reason to believe that the lifetime of the transaction outcome is at least as long as the resources it is coordinating.

That's the crux of the “D”, and of how volatile resources fit in.  The transaction manager should commit (no pun intended) to preserve the transaction outcome for as long as the resource might need it.  A volatile resource is one where the resource manager knows that its resources will never survive application termination.  Passing that hint along to the transaction manager allows the TM to make optimizations in its logging protocol without violating the spirit of a durable transaction outcome.