Page #81 (Chapter 12 - IIS Applications and Microsoft Transaction Server)

	Chapter 12 - IIS Applications and Microsoft Transaction Server
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	What Is MTS?

	MTS consists of several unrelated capabilities lumped together under a single name. Microsoft, recognizing that MTS is not an accurate name for this collection of features, has renamed MTS to COM+ in Windows 2000.

	MTS is an object broker. That means it maintains a list of objects and facilitates other programs' use of those objects. MTS facilitates code reuse. Without MTS, you would have a difficult time sharing objects within your program and between programs. You would have to set up a pool of objects, then devise ways of sharing them without conflict.

	MTS is also a transaction monitor. MTS can monitor and manage transactions—work that must either complete successfully or fail totally across multiple components. For example, suppose you want to send e_mail to an administrator each time an employee changes personal income tax deductions. The transaction consists of all the operations required for the employee to make the change in a database and also all the operations required for the program to compose and send the e_mail message to an administrator. If any error occurs when making the database changes, you don't want the program to send the e_mail. If the database changes succeed, you must send the e_mail message successfully; otherwise, you need to roll back the changes in the database and inform the employee that the program cannot make the changes.

	If you set this up, you would need to write code to ensure that each part of the process completed successfully before committing the transaction. You would also need to write code to roll back the transaction if any error occurred. MTS handles all these issues for you.

	MTS uses components to perform the units of work involved in a transaction. A component and a class are, to the VB programmer, essentially identical. VB programmers discuss classes and objects. MTS programmers discuss components. A component has a specific COM interface, and so does a VB class. A DLL may contain several components or classes, just like in VB. You can't create classes with multiple interfaces in VB (although you can make classes that use multiple interfaces).

	With Visual Basic 6, Microsoft added a design-time property called MTS-TransactionMode that lets you control whether the classes you create can participate in MTS transactions. The property has five settings, as shown in Table 12.1.

	Table 12.1: The Five MTSTransactionMode Settings

	VB Constant

Value

Description

	NotAnMTSObject

0

The class never participates in MTS transactions and does not expect to run under MTS (which doesn't mean it can't run inside an MTS process).

	NoTransactions

1

The class can run under MTS but never participates in transactions.

	RequiresTransaction

2

The class runs under MTS and requires a transaction. If a transaction is already in progress, the class inherits the context for that transaction from the calling object. If no transaction is in progress, the class starts a new one.

	UsesTransaction

3

The class runs under MTS and participates in a transaction if one is in progress, but the class does not start a new transaction.

	RequiresNewTransaction

4

The class runs under MTS and begins a new transaction whenever MTS activates the class.

	WebClasses don't support the MTSTransactionMode property, but standard classes do. That means that although WebClasses don't participate in transactions, they can launch objects that do. Note that components do not have to participate in or begin transactions to run under MTS. You can take advantage of some other features of MTS whether you need transactions or not. These features help speed up Web applications:

	Object caching and pooling  Although MTS doesn't support true object pooling for apartment-threaded DLLs such as those you create with VB (although it may in the future), it does cache one or more instances of the class in memory. Usually, each time you create an object instance, the server creates a new instance of the class. In contrast, after MTS has loaded a class, it keeps it loaded and ready, either forever or for a configurable amount of time. That feature alone is worth using, especially for Web applications in which the object creation/destruction cycle happens for every request. To take advantage of this feature, your code needs to tell MTS when you're done with a component.

	State maintenance  MTS "fools" clients into thinking that they have exclusive use of a component when in fact that component may be shared between multiple clients. That means that you can create a client reference to an MTS component, use the component, do something else, then use the component again. During the time your code isn't using the component, MTS may let another process—or many others—use the component. To the clients, each component acts as if it belongs to them exclusively. MTS creates new instances of components only if none exist or if all the existing components are busy. In other words, you don't have to worry about creating an object, using it, then destroying it as quickly as possible because MTS frees you from those worries. MTS state maintenance saves not only resources, but also a great deal of server time that would otherwise be spent creating and destroying objects.

	Data sharing between components  MTS lets you share properties between multiple components. In a standard application, you use global variables and constants to share data. Because MTS objects are shared between multiple clients, you can't store state inside the objects themselves. MTS uses an object called a Shared Property Manager to manage data shared between MTS components.

	Process isolation  MTS isolates your Web server from the effects of misbehaving components. When you run components in the root Web, any component that crashes can also crash the server. Components running inside MTS don't crash the server. You can group components into Packages, each of which can run in a separate process. There's a performance penalty for cross-process object communication. When maximum speed is imperative, you can run components as a Library Package. Library Packages run in the client's process space; therefore, they're faster (but less secure) than components that run in their own process space.

	Security  MTS gives you fine-grained security. You can control security down to the interface level (note that's below the object) in MTS. MTS has role-based security, which means that you create roles, each of which can have different permission levels. You can assign user accounts to those roles, then have MTS manage access to resources based on a user's role.

	In-memory databases  With COM+ in Windows 2000, Microsoft has added support for in-memory database tables. Keeping database tables in memory can provide a huge leap in performance and scalability, because memory access is an order of magnitude faster than disk access. Depending on your needs, this feature alone may be worth upgrading from NT 4.