A Developer Introduction to the Kernel Transaction Manager (KTM) and Windows Transactional File System (TxF)

The lack of operating system support for transactions has resulted in some
tedious data management solutions that needed to be hand-implemented by
developers to minimize the risk of data corruption in the event of application
crashes or unexpected system shut-downs such as blue-screens. The typical
pattern to reduce the chance of data corruption is to narrow an operation
against a non-transactional resource down to the most ‘atomic’ operation
possible such as a file move or rename, and then to use temporary resources
that can be swapped into place once a long chain of non-transactional
operations have been completed. The need to hand-implement this pattern is
tedious, and fails to take into account any other transaction scopes that exists.

To address this problem, Windows Vista shipped with the Kernel
Transaction Manager (KTM)
for use in C++ applications. The KTM
works with the Common
Log File System
(CLFS), which is another new operating system feature that
is available in Windows Server 2003 R2 onwards, to provide basic transaction
support to both system and application developers. The client API of the KTM is
quite simple – functions to create, commit and rollback transactions exist, and
the Windows
Distributed Transaction Coordinator
(DTC) has also been extended in Windows
Vista to support a new interface called IKernelTransaction
that allows the KTM to work with other resource managers like a SQL
Server database.

The KTM allows any resource manager to enlist its services to implement either
volatile or durable transactions. Volatile transactions do not use a log file,
while durable transactions use the facilities of the CLFS to provide recovery
support in the advent of system failure. Vista ships with two resource managers
that implement durable transactions – the Transactional File
System (TxF)
and Transactional
Registry (TxR)
. Most developers will never actually write a transacted
resource manager, but will instead deal with existing resource managers like
the TxF. The TxF can operate against non-networked non-encrypted
NTFS file systems, and allows multiple operations against a file to be
conducted in a transactional manner to guarantee the file’s consistency.

The handle-based nature of the Windows API makes the use of the TxF
quite easy, a transaction is created either directly through the KTM APIs or as
a distributed transaction through IKernelTransaction, and this transaction
handle is passed through to CreateFileTransacted, which is a transaction-aware
equivalent of CreateFile. The file handle returned by CreateFileTransacted can
then be passed through to any normal file API such as WriteFile and ReadFile,
minimizing the rework required to retrofit transactions to an application. For
file-based APIs that do not take a file handle, a transacted function that
takes a transaction handle rather than a file handle has been added –
MoveFileTransacted and SetFileAttributesTransacted are good examples of this.

The Transactional Registry (TxR) API works in a very similar manner to the
TxF, with RegCreateKeyTransacted and RegOpenKeyTransacted returning a registry
key handle that is transaction aware and can be used in standard registry
functions like RegCreateKey.

By providing transactions at an operating system level and allowing these
transactions to be enlisted with the DTC and take part in transactions that
span other resource managers like databases, the KTM is a huge advance in
providing the APIs for developers to create robust and reliable applications.
Only minimal changes are required to introduce the KTM, the TxF and the TxR in
an application, with transaction information stored in Windows handles and
passed into existing APIs.

More by Author

Must Read