Home     Products      Support      Corporate     Sign In 
Support Knowledge Base, Article 663
Product
General
Title
Transactional File Manipulation in ASP
Solution

Transactional File Manipulation in ASP

By David Wihl

By integrating Microsoft Transaction Server (MTS), IIS 4 introduced the notion of a transacted web page. A transacted web page permits all components in a given ASP page to act in concert. Using well-known ACID properties, all the actions on a page will either complete successfully, or roll-back to a clean pre-transaction state. This powerful notion is commonly applied to databases, and can now be even more dramatically applied to traditional file operations.

<%@ TRANSACTION = Required %>

Transactions are well understood in the database world. A database programmer creates a transaction, and performs a series of database updates. If the updates are successful, the transaction is committed, making the changes permanent. If there is a failure in any single update, the transaction is aborted and all other updates are undone.

That's great if the only persistent store you use is databases. However, most applications use a combination of regular files and databases. Life would be great if all of your files operations could also participate in the transaction. Wouldn't it be wonderful if you start a transaction to perform database and file updates? Then if any single update failed, every other update would automatically be rolled back, guaranteed.

MTS, in concert with IIS, provides the infrastructure to allow this. MTS allows any arbitrary set of objects to participate in a transaction. Any article on MTS will talk about MTS objects using SetComplete or SetAbort to tell MTS that a given update succeeded or failed. Less commonly known is the back end of MTS that performs the actual Two Phase Commit including enforcing the ACID properties of the transaction. Setting complete or abort status by an object is easy. Performing the underlying guaranteed commit or roll back is hard.

Enter the Resource Manager

By developing a Resource Manager, it is possible to extend the MTS back end and allow ACID operations on any resource that provides durability. Microsoft ships Resource Managers for SQL Server database operations (via OLE-DB) and Microsoft Message Queue. There can also be Resource Managers for e-mail, the NT account database, or even the Registry. Once you realize how useful transaction based programming is, you start wondering why this incredibly useful technique isn't more readily available.

The reason is that it is hard. Building a good Resource Manager requires expert programming skills, on the level of writing a device driver. But like a good device driver, once done, it is incredibly useful for a huge variety of things.

At SoftArtisans, we've built a Resource Manager for atomic file operations, such as Create, Copy, Rename, Delete.

The object creation is normal. The method invocations look like the Scripting.FileSystemObject. The big difference is a Resource Manager working behind the scenes to ensure that all of these actions respect ACID properties. If any single action fails, all other actions will automatically be rolled back. The developer doesn't have to worry about any steps that have been executed prior to the failure. The File Resource Manager, working with MTS's Two Phase Commit, will automatically guarantee atomicity and durability of the transaction.

The implications are enormous! You can now have automatic synchronization between your database operations and your file operations. That means no more orphaned files on disk, without corresponding database rows.

If a Resource Manager for e-mail was currently available, you could performany combination of updating a database, changing files, and sending e-mail all in a single transaction. If any single action failed, nothing else would be executed, all without complicated error handling by the developer.

Down the Road

Microsoft expected to have transactional capabilities in Windows 2000. As of this writing (May 1999), it appears that this will not happen. Microsoft is trying to make the entire file system transactional. We took a subset of the problem and successful implemented transactional atomic file operations. This is still such an incredibly useful subset that we felt it was not necessary to wait until the next major upgrade of Windows.

Expect to see other Resource Managers in the near term. Exchange is rumored to add Transactional Capabilities to CDO. Over time, it makes sense that any durable action should be transaction-enabled through an MTS Resource Manager.

David Wihl (wihl@softartisans.com), is President of SoftArtisans, a leading developer of Active Server Components.

Created : 7/11/2003 5:55:27 PM (last modified : 7/11/2003 5:55:24 PM)
Rate this article!
 
Comments