Robert Coleridge
Microsoft Developer Network
November 1998
Summary: Discusses the changes to the Duwamish Books Data Access Layer (DAL) component for integration with Microsoft® Transaction Server (MTS). (2 printed pages) Assumes familiarity with the concept of a data access layer as detailed in my article "Designing a Data Access Layer."
In Phase 1 of Duwamish Books, a monolithic desktop application, the use of persistent database connections and connected recordsets was perfectly acceptable and easily understood. In a desktop application the developer does not have to worry about such things as scalability or remoting of data when writing the code. When I say the desktop model of Duwamish is more easily understood, I mean that because the code accesses the data more directly the code is not as obscure as code that has to access the data through multiple other layers. As the sample moved from the desktop to a client/server architecture, and eventually a three-tier architecture, it needed to change how it accesses the data, how it maintains or doesn't maintain database connectivity, and so on. In a distributed world, you do not want to hold open a database connection any longer than is necessary because this will tie up resources, both on the server and the middle tiers. Persistent connections are not scalable and are heavy resource consumers; therefore, we made the decision to move to a connectionless object model for the DAL.
Incorporating MTS into the project allowed us to reduce the 12 methods of the DAL to only two: ExecQuery and GetRecordset.
Table 1. The DAL Methods in Phase 3 and 3.5
| Phase 3 method | Changes for Phase 3.5 (under MTS) |
| BeginTrans | Obsolete because MTS handles the transaction initialization automatically. |
| CloseConnection | Obsolete because the DAL is now connectionless. |
| CommitTrans | Obsolete because each MTS-enabled object now votes as to its success or failure. The commitment of the transaction is left up to MTS, depending on the voting results and the object's transactional requirements. |
| DisconnectRecordset | Obsolete because the DAL is now connectionless. |
| ExecQuery | The only change made to this method was to move from a BeginTrans/CommitTrans paradigm to a success/failure voting scheme. |
| GetConnectedRecordset | Obsolete because the DAL is now connectionless. |
| GetRecordset | The only change made to this method was to move from a BeginTrans/CommitTrans paradigm to a success/failure voting scheme. |
| IsInTransaction | Obsolete because the DAL is now connectionless. |
| OpenConnection | Obsolete because the DAL is now connectionless. |
| PutRecordset | Obsolete because the DAL is now connectionless. |
| RollbackTrans | Obsolete because each MTS-enabled object now votes as to its success or failure. The commitment of the transaction is left up to MTS, depending on the voting results and the object's transactional requirements. |
| DataComponentsInstalled | No longer necessary due to Setup changes. |
As you can see, the addition of MTS greatly simplified the object model for the DAL. The new DAL is essentially a new component and is not backward compatible with the Phase 3 DAL.
With the transaction processing integral to MTS, we no longer need to have methods like BeginTrans, RollbakcTrans, and CommitTrans. We removed these methods from the DAL and simply inserted the MTS SetComplete (CommitTrans) method or SetAbort (RollbackTrans) method where appropriate. Bear in mind that these two replacements are not functional equivalents—they are simply voting methods. For more details on using transactions in MTS, see Michael Zonczyk's article "Hoisting the Duwamish Books Components into MTS."
Adding MTS to a data access layer, such as the Duwamish DAL, can take some time to implement, but as you have seen, the benefits well outweigh the costs.