Transactions in SnapDAL

No data access api would be complete without a discussion of how it supports transactions. In the beginning, SnapDAL had some fairly simple goals and philosophies in regards to transactions. These are still supported. They are:

• Only the application code originating a transaction can fully understands what a constitutes a transaction at any point in time. In a call that aggregates many different objects into a single "atomic" action, it is the caller that knows when to begin, commit or rollback a transaction.
• Code evolves over a period of time and not all at once. SnapDAL will always support sharing transactions with other ado.net code that doesn't use SnapDAL. This helps you while you migrate to SnapDAL, if you use libraries from other projects, or developers, or companies that support transactions in a different way.
• No transaction techiques will be used that while interesting or "advanced" are more difficult to use than the functionality already provided by ado.net. Note that Indigo will (read might) provide an automatic enlistment capability to replace the aging Enterprise services namespace.

These goals mean that there will not be an attempt by SnapDAL to provide a COM+ style automatic enlistment procedure, even though there are good arguments for doing so. Currently there are one ways of sharing a transaction between calls: pass a transaction with each method call. If an application originates the call, it can originate a transaction. The application code can accept a transaction, either by class properties or by overloaded method calls. Every DataFactory method has overloads that accept transactions. Call this the manual way. It's actually easier than you think to get right and because it's explicit, it's very easy to understand and troubleshoot. It's kind of ugly too, and does muddy the encapsulation that you worked so hard to build into your OO designs.

Currently under development is a two-phase commit mechanism that will be provide by the DataFactory's BeginTransaction mechanism. Any caller can call BeginTransaction, then commit or rollback, but only the first caller would actually be able to commit finally. Details to follow.