Some of the main topics in this chapter are
This chapter provides an overview of two key components Microsoft offers for distributed transaction processing: Distributed Transaction Coordinator (DTC) and Transaction Server. DTC was introduced with SQL Server 6.5. It greatly simplifies the process of developing and deploying distributed applications. Transaction Server 1.0 was released in January 1997 and builds on the functionality offered by DTC. It provides a COM-based programming model and forms the basis of an entirely new computing architecture that you can use to build state-of-the-art distributed systems.
As a potential tool for implementing transactions involving more than one SQL Server (distributed transactions), the 2PC protocol has some strengths and some weaknesses. Although it solves many problems associated with distributed transactions, it can be difficult to implement and manage.
A complete discussion of 2PC is beyond the scope of this book. A brief overview, however, will help you to understand the rudiments of this technology and the powerful new components that Microsoft has added to make the use of distributed transactions more practical. This discussion of 2PC is a deliberate simplification designed to help managers and SAs understand the role and importance of 2PC in distributed transaction processing. Developers wanting to use this technology are urged to seek additional resources, such as the Guide to Microsoft Distributed Transaction Coordinator, which is provided with the product.
Assume that you're running an application on a desktop computer that needs to update databases on two SQL Servers as part of a single transaction (see Figure 57.1). Naturally, you want them both to be updated, or you would like the transaction to fail and both servers to be left unchanged. You could then try the transaction again later; but most important, the data on each server would remain in a consistent state, and the data regarding the proposed transaction also would remain consistent. The transaction either happens or it doesn't--all or nothing.
In this diagram, a client is attempting to work with two SQL Servers as individual entities. The transactional capability of SQL Server alone is not sufficient in this scenario.
Trying to implement this behavior is more difficult than it might appear at first. For this technology to be useful, it must continue to work when one or more computers fail at the worst possible moment. Anyone who has used computers for even a short period of time knows that they can and do fail. SQL Servers have the capability to log transactions in a write-ahead log and either commit them or roll them back. This capability is robust enough to handle system failures and power outages. However, this facility alone is not enough to implement distributed transactions.
Suppose that your application has sent update instructions to both databases and is ready to commit the transaction. It could send a commit instruction to the first server (call it A), wait for a confirmation, and then send a commit to B. But what if B or the communications link between the client and B fails after A has committed and before B gets the message? The rule has been broken. You did not achieve an all-or-nothing transaction. You could try sending the commit instruction to both at the same time, but this is really no better.
Two additional elements are needed. You must ask your servers to achieve a prepared state in which they can durably commit or roll back. In other words, if the computer fails in the prepared state, it can be restored to the prepared state, still ready to commit or roll back. Additionally, you need a commit coordinator to help this process take place. Of course, the application itself could take on this role, but managing the states of multiple SQL Servers in a durable manner is a lot to expect from a typical application program.
With these additional elements, the following process can occur (see Figure 57.2). When an application is ready to commit its updated information, it notifies the coordinator. The coordinator instructs the SQL Servers to prepare to commit. They each attempt to adopt the prepared state. If one (or both) fails, the coordinator records in a log that the transaction has failed and advises both servers to roll back the transaction. A failed server checks with the coordinator when it was running again and finds out that the transaction should be rolled back. The coordinator also can recover from a failure and remember the status of the pending transaction.
A distributed transaction using 2PC protocols is depicted in this figure. The transaction coordinator is shown as a separate machine for clarity but can actually be implemented on one of the Database Servers.
If both servers report that they have successfully prepared, the coordinator records that the transaction should commit and advises both servers to commit the transaction. If a server or communications link fails at this point, all three components (the two SQL Servers and the coordinator) are able to restart and achieve the prepared state again. The coordinator's log "reminds" them all to commit the transaction. If the commit takes place (as it usually does), the application has successfully completed a distributed transaction.
A full analysis of all the possible failures that could occur, at all the worst times, requires a good deal of thought. For this discussion, suffice it to say that the 2PC mechanisms described provide a reliable and automatic problem resolution in most failure situations. A few conditions still require human intervention, however. One such case is an extended outage of a server or communications link that leaves elements in the databases locked. If the locked element is a table of all available rooms at a hotel, the front desk personnel will undoubtedly expect the situation to be resolved quickly.
SQL Server has included support for the 2PC protocol in the past. Application programmers using the C/C++ programming languages could access 2PC functionality by using the DB-Library interface provided by Microsoft for developing SQL Server applications. Procedures were provided on servers that enabled them to take on the role of commit coordinator.
DTC adds important new components to help implement distributed transactions and make the management of 2PC a practical undertaking. Each server has a full DTC service that coordinates transactions with other servers. Using DTC, a server can take on the role of commit coordinator for certain transactions. In addition, DTC can help resolve problem (or in-doubt) transactions by communicating with other DTC services running on other servers involved in a transaction.
A client-side interface to DTC is available for Windows NT and Windows 95 computers. This interface enables developers to create applications by using distributed transactions and leverage the facilities provided by the full DTC service running on SQL Servers. The client components of DTC do not include a full DTC service, even on Windows NT clients. Also, the DTC client is available only for 32-bit versions of Windows (Windows 95 and Windows NT).
TIP: It's possible for a stored procedure running on a SQL Server to launch a distributed transaction on behalf of a 16-bit client. Therefore, older Windows clients can still benefit from DTC functionality.
In addition, a set of management utilities has been added to SQL Enterprise Manager. The utilities include graphical tools that enable you to dynamically monitor the state of transactions on SQL Servers running the DTC service. You can open multiple windows to monitor transactions occurring on multiple servers from a single workstation. The DTC extensions to SQL Enterprise Manager also enable an administrator to manually resolve problem transactions arising from equipment or application failure.
NOTE: Although SQL Enterprise Manager can be run on Windows 95, DTC utilities are available only when using SQL Enterprise Manager on a Windows NT computer.
For application developers, DTC offers new tools to support distributed transactions. A new statement in T-SQL, BEGIN DISTRIBUTED TRANSACTION, enables the creation of stored procedures that use DTC to coordinate transaction execution on multiple servers. This dramatically simplifies the development of stored procedures involving remote servers. In addition, an API for C/C++ programmers that conforms to the OLE Component Object Model has been provided for DTC. Using this interface, an application developer can create transaction objects and enlist the services of transaction resource managers and transaction coordinators to process those objects.
At this point, Microsoft SQL Server is the only available resource manager, but an OLE Transaction interface definition has been published, Microsoft and other software companies will create other resource managers. Some level of interoperability is offered with several existing transaction-processing monitors, including Encina, Top End, and TUXEDO, and particularly with Microsoft's new Transaction Server (formerly code-named Viper).
The DTC server components are installed automatically when you set up SQL Server 6.5 or upgrade SQL Server 6.0 to version 6.5. You can start the DTC service just like any other service using the Control Panel on the local computer, or using the Services dialog box in the Server Manager utility provided with Windows NT Server. You also can start the service by using the SQL Service Manager or SQL Enterprise Manager.
The rest of this section focuses on the DTC capabilities added to SQL Enterprise Manager. This administrative tool has been enhanced with functionality to completely monitor and manage DTC capabilities. To start the DTC service with SQL Enterprise Manager:
The DTC Configuration dialog box enables you to control the behavior of the DTC service. You can configure parameters that affect viewing transactions in the Transactions window, the tracing information sent to the Trace window, and the location and size of the DTC log file. To configure the DTC service:
Use this dialog box to configure the displays that monitor the distributed transaction coordinator service and its behavior.
To view the status of active transactions:
This figure depicts a DTC Transactions window for the server HQSRV1. There are 3 active transactions and 1 preparing to commit.
You can manually resolve in-doubt transactions by right-clicking the transaction in the Transactions window and selecting the appropriate action.
CAUTION: You should not manually force transactions until you thoroughly understand the interaction of all members of a DTC system. Please review the Guide to Microsoft Distributed Transaction Coordinator carefully before using this utility to resolve transactions.
To view the traces being sent (at the level you configured DTC to provide):
A DTC service maintains statistical information about its performance. To view the statistics that have accumulated for a DTC service:
TIP: The statistics for a DTC service are cleared and restarted whenever the DTC service is stopped and restarted.
Microsoft Transaction Server 1.0 (MTS) was released in January 1997 and builds on the functionality offered by DTC. It provides a COM-based programming model with a relatively simple Application Programming Interface (API) that makes it easy for developers to create powerful, distributed applications. Applications are created largely as though they were designed for a single user to execute on a desktop computer. With minor additions, these applications can be invoked in a Transaction Server environment. Transaction Server provides all the needed additional capabilities to make the application multiuser and leverages DTC to provide distributed transaction processing. Transaction Server, therefore, forms the basis for a powerful three-tiered distributed computing architecture.
This figure depicts a DTC Statistics window for the server HQSRV2.
A simple example of the way an MTS environment might be set up is provided in Figure 57.7. Desktop PC clients can be either so-called "fat" Win32 systems (running either Windows 95 or Windows NT) or "thin" clients running a Web browser. MTS servers manage packages of components. These components can be developed in-house or purchased from third-party software vendors. They are then pulled together in one or more packages that you can deploy as a unit sharing resources (for example, memory) and security settings. MTS also manages a shared pool of ODBC data connections to a variety of data providers, which can be traditional database servers or files on a mainframe.
Although the preceding example describes three tiers, there is nothing inherent in the design of MTS that limits it to this structure. It is possible to break a computing system into more than three logical tiers, and MTS is designed in a manner that makes it straightforward to implement a variety of system architectures, including multitiered designs. The three-tiered model is natural in some respects and is starting to be widely used but need not be the only deployment alternative with MTS.
NOTE:The operating systems and applications that are installed on PCs have become much larger as they have grown in sophistication. With the advent of the HTTP-based Web browser, application developers started exploring the capability of using this relatively "thin" tool as the basis for server-based applications. The traditional application architecture with its executable files and Dynamic Link Libraries (DLLs) has been characterized as "fat" because of the amount of information (programs, configuration files, and data) that must be stored on the client.
It's worth noting, however, that browsers (from Netscape, Microsoft, and others) continue to get "fatter" as more features are added. In addition, browser-based applications have not yet reached the level of performance and sophistication offered by the more traditional Win32 client. It remains to be seen how fat the thin client will need to become to match the functionality offered by Win32 clients.
This figure depicts a sample MTS environment showing various elements of a three-tiered architecture.
The next few sections provide an introduction to Transaction Server. You learn how to install the product, go through a quick tour of MTS in action, and review the product's features.
MTS can be installed in two ways--as a production server or as a development server. If you plan to experiment with MTS and use the development tools to create distributed applications, you will want to install the Software Developer's Kit (SDK) in addition to MTS. If you are implementing a solution that has already been developed, you will probably prefer to install only MTS. The procedures for installing MTS and its options are provided in the following steps:
This dialog box enables you to select a development installation of MTS with the SDK and samples or a production installation including only the MTS product itself.
Use this dialog box to select the individual components you want to install.
Transaction Server is used to deploy mid-tier logic implemented in the form of ActiveX components. These objects receive requests from clients, apply some sort of logic (for example, business rules) to the requests, and then call on appropriate resource managers to resolve the requests. The ActiveX components can be written with a variety of languages, including those listed in Table 57.2 in the section "Packages of Components" later in this chapter. After these components are written, they are combined to form packages. The packages are then deployed, usually on Windows NT servers, to act as intermediaries for clients wanting to access shared resources.
Because of MTS's capability to manage the linkage between many clients accessing many resource managers (for example, databases) while applying application logic, the application architecture you can create by using these building blocks has some desirable characteristics:
Much of the distributed nature of the MTS product comes as a direct result of the use of the Component Object Model (COM) and Distributed Component Object Model (DCOM) as the basis for MTS component building. A full discussion of these specifications is beyond the scope of this book--see Special Edition Using ActiveX from Que. A brief introduction, however, is included here as an aid to understanding the underlying mechanisms that make MTS work.
The basic COM specification uses a message-based architecture to enable one process to communicate with another. Each COM component is implemented as a server. The word server is obviously used in a different sense here than a file server of some sort. The component, or server, does create its own context and serves as an interface, or multiple interfaces, to the outside world. Calling processes can use these interfaces to access the services offered by this component. There are two types of servers--in-process or local server. Both types of components execute on the same machine as the caller. In-process servers are usually implemented as DLLs, and therefore they run in the same process as the caller (see Figure 57.10).
This figure depicts a simple call from one process to an in-process server.
Local server components run in a separate process on the same computer, as shown in Figure 57.11. Through the use of a proxy and a stub, the calls from one to the other are easily handled. The proxy looks like the actual component being called to the calling process. The proxy communicates with the stub through an Inter-Process Communication (IPC) mechanism. The stub then communicates with the component, appearing to be the original calling process. The caller and component have been separated but remain on the same machine.
In this figure, a call is made from one process to a local server process running on the same machine.
The DCOM specification adds a third type of server--remote server. In this instance, the IPC mechanism used for local server calls has been replaced with a Remote Process Communication (RPC) mechanism. The original caller and component implementations are retained, as is the use of the proxy and stub; only the communications mechanism has changed (see Figure 57.12). The substitution of remote servers for local servers is nearly transparent to the developer, making the process of partitioning an application into components much more straightforward. The application logic can be located where you want to put it, and the "plumbing" between components is managed by MTS.
The DCOM remote server implementation is shown in this figure.
After you have either purchased off-the-shelf components, written your own, or both, you can create collections of components called packages. You can manage a package of components as a unit. The components in the package can share security settings and can access other shared resources through the use of MTS's Shared Property Manager (SPM). They also can share a pool of ODBC connections to database resources. Allocating memory and processing on a one-to-one basis with clients becomes inefficient when handling large numbers of clients. A shared pool is more efficient and scales better as the number of clients grows.
When access to distributed database resources is required, the services of Microsoft's DTC (described in the first part of this chapter) are used to efficiently provide a message-based architecture capable of maintaining the atomic nature of transactions across machine boundaries. Communications with database resource dispensers are handled by using a variety of protocols. Currently, OLE Transactions (OLE TX) and XA is used. Other protocols such as Transaction Internet Protocol (TIP) and SNA LU 6.2 will be added in the future.
The MTS development environment provides a flexible programming environment. As already noted, the focus of most developers is on creating components designed for single-user environments without regard for distributed applications issues. They can work in a variety of languages, including those listed in Table 57.1.
| Language | Manufacturer |
| Delphi | Borland |
| Visual Basic | Microsoft |
| Visual C++ | Microsoft |
| Visual J++ | Microsoft |
| PowerBuilder | PowerSoft |
| Visual Café | Symantec |
The tool used to package components, and then deploy the packages, is the Transaction Server Explorer. This administrative console for MTS is a graphical utility that enables you to manipulate and control the components that build a multitiered MTS architecture. In addition to these component-based activities, you also can use the Transaction Server Explorer to start and stop DTC, change the service account settings, or perform other administrative tasks. To use the Transaction Server Explorer to manage MTS:
The Transaction Server Explorer is shown here with My Computer selected in the left pane and the contents of My Computer displayed in the right pane.
TIP: Right-clicking an object generally opens a context-sensitive menu with choices pertinent to the object selected.
Use the Package Wizard to install prebuilt packages and to create empty packages that then can be filled with components.
ActiveX components created with a variety of languages can be integrated into a single package for deployment on this computer or to be exported to other machines.
The General tab of a package's Properties dialog box shows the Package ID and a description of the package.
The Security tab enables you to set more stringent authorization requirements for components in this package.
Microsoft plans to continue the evolution of MTS into the future, where it will become a key component of multi-machine architectures. Microsoft has publicly announced plans to add data-dependent message routing (useful in partitioning large applications) and durable queues that would maintain the queue of messages even in the event of catastrophic failure. These and other features will likely be delivered by, or derived from, the Microsoft Message Queue (MSMQ) Server, a product that was code-named Falcon. It will be interesting to see how these technologies are combined to extend and improve the powerful features already included in the first release of MTS.
By clicking the Transaction List icon in the left pane, you display any active transactions in the right pane.
Transaction Statistics reflect the activity on this server since the DTC service was started or since the settings were last cleared.
© Copyright, Macmillan Computer Publishing. All rights reserved.