transactional COM + applications

Program

In the previous chapters we have seen several run-time features that COM + provides that simplify the development of distributed components that can be used to create scalable, maintainable ASP applications. MTS introduced the transaction model first, and its design simplifies the development of component-based Distributed transaction processing system. As an inheritor of MTS, COM + enhances and expands the powerful transaction model of MTS, providing more flexibility and simplicity to the system.
The COM + transaction model removes complex transaction processing code that is required to coordinate distributed transactions through MS DTC. But more importantly, the COM + transaction model transparently blends distributed transactions with COM + components.
COM + transactions implemented by using the Declaration (declarative) attribute are sometimes referred to as declaring transactions or automatic transactions. The declaration attribute can be specified externally to the component's implementation. To do this, you must:
? Configure the component's transaction support properties, use component Services Explorer, or use a constant value in the component type library.
? The result of the voting of a transaction can be taken by an elective reorganization.
By interacting with MS DTC on behalf of a component, COM + automatically handles the rest of the complex and lengthy transaction details.
Because COM + relies on MS DTC coordination transactions, a single component can perform operations on different types of data sources in a single COM + transaction. You can affect ADO or OLE DB data access when you use COM + to declare transactions with components. The possible combination of data sources that can operate in a single transaction is endless. For example, COM + objects can modify data in a SQL Server database, send MSMQ messages, and manipulate data from mainframe systems, all in the same COM + transaction.
Now that we understand the benefits of COM + transactions, let's continue to learn how to use the declarative transaction model effectively and understand what COM + is doing behind the scenes.
19.3.1 Transaction Support Properties
As mentioned above, the transaction Support property of each COM + component determines how the component will participate in COM + transactions. When you activate a COM + object, COM + determines the transaction support for the object and whether the creator has provided an existing transaction. Based on these two information, the COM + runtime will provide an object in an existing transaction or a new transaction, or there is no transaction at all. Every COM + object can be activated, regardless of whether there is a transaction. For this reason, components that leverage transactions are often referred to as transactional components, and components that do not take advantage of transactions are called non-transactional components.
There are five possible transaction support property options when using COM +:
? Prohibit (Disabled) when the transaction support property of a component is set to Disabled, COM + will completely ignore the transaction requirements of the component. COM + first attempts to activate the object within the creator's environment. If the creator's environment is invalid or incompatible, COM + activates the object in a new environment. Because an object may inherit or not inherit the creator's environment, the object may also share or not share the creator's transaction.
? does not support (not supported) An instance of a component will never participate in a transaction when the transaction support property of the component is set to not supported. This setting is designed for COM + components that do not have access to the data source, and the result is that the component has no transaction overhead. However, an object with the Transaction support property of not supported is always activated in a new environment. This contradicts disabled, and disabled objects can share the creator's environment. NotSupported is the default transaction support property value.
? Support (supported) when a component's transaction support property is set to supported, an instance of the component participates in the existing transaction. However, the component does not require a transaction and the component performs well in the absence of a transaction. The supported property simply represents a support transaction, rather than requiring a transaction to exist.
? Required (Required) when the component's transaction support property is set to Required, an instance of the component is always executed within the transaction. Before activating a COM + object, COM + uses the creator's transaction, if present, or the new transaction provides the object. In either case, the component instance is always executed within the transaction.
? Need to create a new (Requires new) when the component's transaction support property is set to Requires new, an instance of the component is always activated in a fresh transaction, that is, a transaction is created specifically for this object, regardless of whether there is an available transaction. This setting is required to complete the work in a transaction, but it must be designed with components that are separate from all other transactions. When you use this setting, COM + objects will never run in the creator's transaction. The new transaction is completely independent of the creator's transaction.
1. Set Transaction Support
The transaction support property of a component can be configured using the Component Services Browser (Component service EXPLORER,CSE) or a default transaction support setting is specified in the component's type library. It is useful to specify the transaction support attribute of a component in the type library of a component, because the risk of incorrectly configuring components can be reduced when using CSE to remove one manager from performing this task. However, it is important to remember that the Transactionsupport attribute specified in the component's type library is a default value that can be overridden using the Component Services browser.
When you configure the transaction support property of a component using the Component Services browser, simply open the Component Properties dialog box for a COM + application. Select one of the five possible transaction support property settings from the Transactions tab, as shown in Figure 1 9-5.

If you are using V C + +, you can set a default value for the transaction support property of a component in the component type library, simply by adding the corresponding line in the definition of the Interface Definition language (I) of the component. When the component is added to a COM + application, COM + reads the type library and automatically uses the transaction support property setting that is stored in the type library as the default value.
Visual Basic 6.0 also allows developers to specify a default value for the Transactionsupport property setting of a component by changing the MTS Transaction Mode property of the class module. Don't let the name of this attribute deceive you, the MTST Ransactionmode property works with MTS as well as COM +. When you compile a project, Visual basic places an equivalent constant value for the setting of the transaction support property in the component's type library, as shown in Figure 1 9-6.

Note that the technical term for the MTS Transaction mode value in Visual Basic is not exactly the same as the terminology in the Component Services browser. However, there is no need to worry that each Transaction support attribute level has a corresponding MTS Transaction mode setting, except for disabled (COM + is new). All possible MTS Transaction mode properties and their equivalent COM + Transaction support properties are listed in table 19-1.

When a component is added from the Registered Components list, because the Component Services browser does not read the type library, the component's type library is applied as long as it is added to the COM + application using the Add File dialog box transaction Support property settings. Conversely, COM + components that are joined from registered components are configured with the default transaction support property, not supported, if the component service browser is not used to modify their configuration.
19.3.2 Activities and synchronization
When a transaction processing system provides services to many users, it can receive simultaneous calls from the customer. Therefore, transaction processing systems must consider issues such as multiuser concurrency, synchronization, and thread management. COM + is able to handle these issues and allows you to create components that are executed in a multiuser distributed environment that are created in the same way as components that are created as a single user service.
COM + accomplishes this amazing task by using activities (activity). In MTS, an activity is a group of objects that are running on behalf of a single customer. In COM +, an activity is an environment group that runs on behalf of a single customer and may contain one or more objects. However, this is only a small difference, and it can be thought that the environment is the most internal object container.
Activity ensures that two objects serving the same user are not executed concurrently. Objects in an activity are synchronized to prevent execution in parallel in this activity. Activities can consist of several environments (including objects) that can be run in separate processes or run on separate machines (with a slight limit). For these reasons, an activity is sometimes referred to as a single logical thread running.
Why is object synchronization so important? Consider a worst-case scenario where two objects representing the same user service attempt to access the same resource at exactly the same time. Each object has to do its own operation, blocking the operation of other objects. This condition is called a deadlock. An activity can prevent a deadlock, which is by allowing only one object at a time to represent a
The user runs to realize. In addition, activities play an important role in helping COM + manage thread buffering.
In MTS, the synchronization of an active object is implemented by connecting the activity to a single physical thread, or an STA. Objects in an activity cannot be executed concurrently because there is only one physical thread per activity. In addition, COM + uses a complex locking mechanism to ensure synchronization in the activity.
Each activity retains a single exclusive lock. When a method is invoked in an object and the object's environment exists in an activity, COM + first attempts to obtain an active lock before allowing the method call to be processed. If a lock is obtained, the call is processed by the object until the method call completes before the lock is unlocked. If a lock is not obtained, the method call is blocked until a lock is invoked. Although the locking process is more complex, from a high-level perspective, COM + uses logical activity to synchronize multiple environments with multiple objects, essentially a separate lock for each activity. The process of using the lock is shown in Figure 1 9-7.

The environment can exist in the creator's activities or in a new activity, or there is no activity at all. However, a single environment cannot span more than one activity. To establish and maintain these relationships, COM + creates a unique user identifier, called an activity ID, for each event stored in each environment.
1. Create Activity and Synchronization properties
As the COM and MTS programming models are integrated, the method of creating activities has changed. With MTS, each object belongs to an activity. An activity is automatically created when a VB client uses the CreateObject function or the new keyword (and some expressions), or when the Visualc++ client creates an MTS object using the C o createinstance E x function. In order to create an object in an existing activity, the creator must call the CreateInstance function in the ObjectContext object.
As you can imagine, this leads to a lot of confusion, and MTS developers must be aware of the boundaries of logical activities and properly use standard object creation techniques (CreateObject or CoCreateInstanceEx) or the CreateInstance function of the ObjectContext object.
With COM +, activities can still be created automatically, but the creation of the activity is controlled by using the synchronization property of the component, not on how to instantiate a component. In fact, the CreateInstance function of the ObjectContext object is now functionally the same as the standard object creation technique, and it supports only the backward compatibility of MTS. In addition, COM + provides the ability to activate objects outside of the activity. This avoids the additional overhead of creating the activity and the possible blocking of calls, elevating performance for components that are frequently used as non-transactional "tool" types. If necessary, they can implement their own locking techniques.
As with the transaction Support property, synchronization properties are configured in the Component Properties dialog box in the Component Services browser, as shown in Figure 1 9-8.

There are five possible values for the synchronization property:
? Prohibit (Disabled) when a component's synchronization property is set to Disabled, COM + will completely ignore the synchronization requirements for the component. Just as when the transaction support property is set to Disabled, COM + will first attempt to activate the object in the creator's environment. If the creator's environment is invalid or incompatible, COM + will activate the object in a new environment. If the object inherits the creator's environment, the object can share the creator's activity, not the other. This setting should be used in non-transactional components, and whenever possible, avoid the additional overhead of creating environments and activities.
? does not support (not supported) when the synchronization property of a component is set to not supported, the object's environment will not exist in the activity. However, an object with the synchronization property of not supported is always activated in a new environment.
? Support (supported) when the synchronization property of a component is set to supported, whether the object's environment exists in the activity and whether the environment in which the creator is dependent exists in the activity. However, components with this setting do not need to be active and can be performed well without activity.
? Required (Required) when the synchronization property of a component is set to Required, the object's environment will always exist in the activity. If the creator environment exists in the activity, the new object will be activated in the creator's activity. Otherwise, COM + will activate the object in a new environment that is located in the new activity.
? Need new (Requires new) when the synchronization property of a component is set to Requires new, the object's environment will always be created in the new activity, regardless of the synchronization state of the creator's environment.
As you can see, the options for the synchronization property are very similar to those of the transaction support property. However, some synchronization options depend on some of the values of other component properties. In particular, components that support JIT-activated components or transaction support properties that are supported, required, and requires must be activated in the activity, Also requires the synchronization property to be required or requires New. The synchronization property can be set to disabled or not supported only if JIT activation is turned off and the transaction support property is set to Disabled or not supported. We will discuss more about the relationship between transactions and activities in the next section.
If you think all these configuration options sound confusing, don't worry. Microsoft anticipates that these interdependent configuration options will confuse developers with the ability to create validation in the Component Services browser. If you change JIT activation support or change some transaction support properties that are incompatible with the synchronization attribute, the Component Services browser will prompt with a warning message and automatically adjust the synchronization property to reflect any changes. The warning message is shown in Figure 1 9-9.

The best thing about activities is that they are all performed behind the scenes by COM + and the components do not need to do any additional work, and COM + provides automatic parallel and synchronous services. Additionally, non-transactional components are provided with the ability to prevent the creation of activities. Nevertheless, it is important to understand how the role and activities of synchronization attribute changes and how the environment works behind the scenes in order to design efficient and scalable components. Now that we have a certain understanding of the configurable properties of transactional COM + components, we discuss each phase of the lifetime of the transaction.
Lifetime of 19.3.3 transactions
COM + transaction lifetimes can be divided into four phases, respectively:
? Transaction started.
? Establish and recruit a connection to the resource manager.
? Perform an operation in a transaction.
? Outputs the transaction result and ends.
It is important to remember that a component needs to participate in a transaction only if the transaction support attribute is not disabled or not supported. COM + components can also optionally vote on the outcome of a transaction.
Here's a detailed look at each phase of a transaction's lifetime in a COM + transaction for a single and multiple objects.
1. Start of Business
Using the COM + transaction model, a component does not explicitly start a COM + transaction. Instead, COM + automatically creates a new COM + transaction in two cases:
? Transaction support properties are required components that are activated by non-transactional clients.
? The Transaction support property for requires new is activated by any customer.
A COM + transaction is made up of two parts:
? Logical transactions.
? Physical transactions.
A logical transaction, also known as a transaction flow, is a logical set or logical group of objects that share a physical transaction. On the other hand, physical transactions are basic MS DTC transactions, using the two-phase commit protocol to reconcile transaction results against the data source. When a physical transaction is created by COM +, it is created with the highest level of isolation (serializable) and the transaction timeout interval is specified in the Component Services browser. COM + completely abstracts objects from basic physical transactions, rather than letting us manage transactions through logical transaction flows and the environment of each object.
Although logical transactions can consist of several COM + objects, it is important that transactional flows (logical transactions) always have a one by one correspondence with physical transactions.
The first object created in the transaction flow, called the root of the transaction. The root of a transaction can optionally recruit other COM + objects in the same transaction by instantiating the component, and the transaction support properties of these instantiated COM + components are required or supported. When an object is created in this same transaction, COM + automatically replicates the environment transaction information of the root object to the new object environment, so COM + can maintain the association of all objects in the transaction. The transaction information contains a GUID value called the transaction ID, which COM + uses to identify the physical (MS DTC) transaction. The relationship between objects is shown in Figure 1 9-1 0.

New objects in the transaction that will be recruited into the creator must be created in the same activity. Using MTS, this means that the root object must create child objects using the CreateInstance method of the ObjectContext object. COM + has now made the MTS and COM programming models integrated and no longer requires the Createinstame method, which can be created using the CreateObject function in Visual Basic or the C o CreateInstance function in Visual C + +.
COM + transactions never span an activity, but the activity does not always correspond to the COM + transaction. There may be several COM + transactions for a single activity. If a COM + object instantiates a COM + component with the transaction support property of requires new, the new object will be in the same activity, but in different COM + transactions, the transaction is completely independent of the creator's transaction. The relationship between transactions is shown in Figure 1 9-11.

Physical and logical transactions are typically created automatically by COM + runtime, and COM + allows developers to create COM + objects in an existing MSDTC (physical) transaction. This feature is aptly referred to as "carrying your own affairs" (Bringyour Own Transaction,byot). When developing transactional components, this feature gives developers more flexibility while still leveraging COM + 's simplicity and logical transaction models. With BYOT, components can effectively use a combination of MS DTC and the COM + programming model to perform virtually any transactional task. A typical use of BYOT is to create an MS DTC transaction with different attributes, such as an isolation level below serializable, and then create one or more COM + components in a physical transaction.
2. Establish a connection with resource Manager
After you create a logical transaction and a basic MS DTC (physical) transaction, COM + must ensure that all data modification operations performed by C + + objects on the data source are performed in Ms DTC (physical) transactions. Each connection for each data source must be from enlistment to or registration to the MS DTC transaction.
Once done, all operations are performed through this connection and monitored by MS DTC. Although the entire recruitment process for each connection is done behind the scenes by COM +, it is important to understand how to complete this significant step in the entire lifetime of a transaction.
Resource Manager (RM) is part of the database server that uses COM + to manage persistent data. Therefore, the connection to a particular data source is in fact only a connection to the resource manager. However, the COM + transaction model adds a software layer to the Distributed transaction architecture, called Resource Dispenser (RD).
Instead of confusing resource manager with resource dispenser, they are two different software components for different purposes in the COM + transaction model.
Resource Manager is a simple system service. For example, a database system that manages persistent resources in distributed transactions.
MS DTC uses Resource Manager to coordinate the commit and rollback of transactions, as implemented by using the two-phase commit protocol. Examples of Resource manager include: SQL server,oracle and MSMQ.
Resource Manager, on the other hand, is an in-process dynamic-link library that manages Resource or temporary resources that are stored in the memory of the manager. such as data source connections, network connections, threads and memory blocks, and so on. You do not need to protect these shared resources when a system fails.
Resource Manager can manage buffer pools for reusable resources, recruit or register them automatically in transactions, and provide operations methods and interfaces for COM + objects for these resources. One of the most common non-persistent resources managed by Resource Manager is the connection to the underlying resource manager that controls persistent storage.
Don't let the terminology of resource Manager confuse you. The Resource Manager is the same as the component used to access resources. For example, an OLE DB service component always resides between a client application that uses ADO or OLE DB, or between an object and an OLE DB provider and a data source. COM + Specifies the OLE DB service component as the resource Manager that data
Source as resource Manager. The relationship is shown in Figure 1 9-1 2.

As already mentioned earlier, as resource Manager, these software components are responsible for managing unsustainable resources. But they can also selectively offer two important services:
? The resource buffering resource provides a way to efficiently allocate non-persistent resources by providing a recycled resource to COM + objects instead of creating new resources. When a COM + object finishes using resources, it puts the resource back in the buffer pool so that it or other COM + objects can immediately reuse the resources.
The connection to the data source (Resource Manager) is the most common of the non-persistent resources used. Creating and canceling a connection to the resource manager is an "expensive" process. To effectively provide a data source connection to COM + objects, both the ODBC Driver Manager and the OLE DB service components provide a buffer of resource manager connections, and the reuse or looping of expensive resources is completely transparent to COM + objects or applications that consume such resources.
? Transactional enlistment enlistment (enlistment) is the process of associating or recruiting resource dispenser with Ms DTC (physical) transactions. Once the transaction enlistment is complete, all work is performed by the COM + object through this connection and is monitored by MS DTC and protected in distributed transactions. All operations will be performed as a single unit of work, and the transaction as a whole needs to determine its acid properties. When a logical transaction completes, MS DTC performs a two-phase commit agreement for all participating resource Manager. Transactional enlistment is completely optional, and Resource dispenser decides whether to recruit resources in the current transaction. Transactional enlistment plays an important role in COM + transactions by simplifying the development of transactional COM + components.
COM + accomplishes tasks by hiding complex details of distributed transactions on components. In fact, in this phase of the transaction lifecycle, the only thing to do is to establish a connection to the data source, just as you would normally use ADO, OLE DB, and ODBC. COM + and resource dispenser are responsible for the implementation of resource buffering and transactional enlistment.
3. Perform operations
Once a database connection is established, the COM + object can rely on resource Manager to start the operation.
When the resource manager receives and processes the data, it can use the appropriate method to ensure that the transaction meets the acid requirements. Many resource Manager implements a logging mechanism that provides the ability to roll back uncommitted changes to meet atomicity requirements. The logging mechanism also allows the resource manager to ensure the persistence of transactions by applying or recovering changes caused by unanticipated problems. Locks are used to isolate transaction changes so that other transactions against the same resource manager are not affected by these changes. To ensure consistency, Resource manager typically defines a particular mechanism or rule to protect the integrity of the data.
4. Outcome of the voting business
As mentioned earlier, the environment of a transactional COM + object contains a GUID value called the transaction ID, which is used to correlate multiple objects in a transaction and link a logical transaction to the underlying physical transaction. However, this is only part of the information stored in the object environment. The transaction object's environment also contains two other important information that is used to complete the transaction, whether the voting transaction is committed or terminated. These two pieces of information are:
? Completion sign (done bit) the bit is a Boolean value indicating whether the object should be invalidated, the Ture value shows that the object has completed its work, and can be invalidated, FALSE (default) value indicates that the object cannot be invalidated.
COM + does not detect the value of the done bit until the method call completes. Thus, the done bit value can be changed many times, and its value is meaningful after the method call. The done bit is actually provided by the J I t activation, so it is possible to support J I t activation in the same way as a non-transactional component.
? The consistency flag (consistency bit) consistency bit is sometimes called "Happy bit", which is a Boolean value that shows COM + objects deciding whether to commit or terminate a transaction. The Ture value displays an object attempting to commit a transaction, and the value of FALSE indicates that the object is forced to terminate the transaction.
After the object is invalidated (the done bit is set to ture), the consistency bit is used by COM + for judgment. Therefore, the consistency bit value can be modified repeatedly, even in different method calls, because only the last value before the object is invalidated is the transaction vote. COM + initializes the consistency Bit with the ture value, that is, COM + assumes that the transaction is to be committed.
The relationship between the done bit and the consistency bit and the transaction is shown in Figure 1 9-1 3.

When the root of a transaction is invalidated (the done bit of the environment of the root object is set to ture), COM + assigns the consistency bit of each environment to the transaction flow to determine the transaction result. The decision to commit the transaction is a unanimous decision.
If the consistency bit for all objects in the transaction set their environment to ture, the vote attempts to commit the transaction, all operations performed in the transaction attempt to commit permanently. However, if any object in the transaction sets the consistency bit of its environment to false, voting terminates the transaction, all operations completed in the transaction are rolled back. When either of these scenarios occurs, the COM + call exits the MS DTC, committing or terminating the physical transaction. MS DTC then coordinates the submission or termination of distributed transactions with all enlisted resource manager by using the two-phase commit protocol.
Table 1 9-2 outlines the impact of the done bit and consistency bit on the results of COM + transactions.

We learned what value the done bit and consistency bit can take to commit or terminate COM + transactions. The following describes how to retrieve and modify their values.
The method of the Object context (or I ObjectContext) interface may be the easiest way to programmatically control the results of COM + transactions, since this allows a single method to be invoked to set both the done bit and the consistency bit. Because there are four possible combinations between the donebit and the consistency bit, there are four methods defined by the ObjectContext interface, respectively: SetComplete, SetAbort, EnableCommit and DisableCommit.
As shown in table 1 9-3, the method of each object environment corresponds. Corresponds to a unique combination of the done bit and consistency bit values.

(1) SetComplete method
The SetComplete method tells COM + that a specific unit of work has been successfully completed. By setting the done bit and the consistency bit both force the object to deactivate and vote to commit the transaction for the Ture,setcomplete method. COM + will check the consistency bit in the environment of each object to determine transaction results only when the SetComplete method is invoked in the root object. The following code example shows how to invoke the SetComplete method:

(2) SetAbort method
The SetAbort method tells COM + that the object did not successfully complete its work, and that it wanted to terminate the transaction. If one or more COM + objects call the SetAbort method in a transaction, the entire transaction terminates because the SetAbort method sets the consistency bit to false and the done bit is ture.

(3) EnableCommit method
The EnableCommit method tells COM + that the object can commit the transaction, but the object has not been deactivated. The EnableCommit method completes this task by setting the consistency bit as ture and doing bit for false.

(4) DisableCommit method
The DisableCommit method is just the opposite of the EnableCommit method. The DisableCommit method tells COM + that the object's work is not complete, the transaction cannot be committed at the current date, and the object does not want to deactivate it. The DisableCommit method sets the consistency bit and the done bit of the object environment to false. Because the object is still active, it will remain in its state between the method calls:

(5) Other ways to end a transaction
In most cases, the transaction results can be explicitly controlled through the ObjectContext interface, but there are two other ways to end COM + transactions:
? Transaction timeout (Transaction Timeout) ends the current transaction if the timeout interval value for the transaction configuration is not active in the transaction. When a transaction times out, it terminates automatically. The default timeout interval value is 6 0 seconds. In the Component Services browser, this value can be changed in the Options tab of the Component Properties dialog box. If you are debugging a transactional COM + object, it is obvious that you need to increase the transaction timeout interval so that there is enough time to step through the method call in the COM + object to ensure that the transaction does not terminate automatically.
? The customer releases all references to the transaction root when the customer releases the last reference to the root object, COM + implicitly attempts to commit the transaction. The implied transaction commit process should generally be avoided, as this can cause problems with the host.
One problem with implied submission is that the results of the transaction are not notified to the customer. When the root object invokes the SetComplete method, COM + attempts to commit the transaction before returning control to the caller. If an error occurs while committing a transaction, COM + simply sends an error message to the client. This allows the client application to handle the problem well and possibly try the transaction again. However, because the client is no longer connected to the root object when implicit commits, the client cannot receive the error message if the transaction cannot be committed. The customer is completely unaware of the outcome of the transaction.
The implied transaction commit process also makes the transaction lifetime longer than necessary. When a transaction exists, it maintains a lock on the resource to ensure isolation of the acid property. An open, inactive transaction can prevent other transactions from performing operations on this resource. This can cause performance bottlenecks, severely limiting the scalability of the application. A better approach is to invoke the ObjectContext method to explicitly commit or terminate a transaction.
5. Transaction Survival Summary
The whole process that a transaction experiences during its lifetime sounds complicated, and it is important to remember that the only requirement for COM + components that participate in transactions is to configure the corresponding transaction support properties for them. There are many different technologies that provide the flexibility to commit or terminate a transaction, although it is a little difficult to understand them now, but they make it easier to develop component-based transactional systems.
19.3.4 transactional access to custom resources
How do I perform transactional access to resources that do not provide resource dispenser? Do you need to develop a custom resource dispenser and resource Manager? If you are using COM +, you do not need anything.
COM + provides a new feature, called the Compensating Resource Manager (compensating Resource MANAGER,CRM), which provides an infrastructure to enhance COM + 's ability to support transaction processing.
Compensating Resource Manager provides a simple way to allow non-transactional resources to participate in transactions managed by MS DTC.
CRM is a simpler option for developing a complex COM + Resource Manager and Resource Dispenser while still using MS DTC to coordinate transactions. For example, you can develop CRM to provide transactional access to resources such as file systems, memory, or Windows 2000 registry. The transactional COM + component accesses the interface through the CRM
Resources, and all operations performed by the CRM are protected by an MS DTC transaction.
In addition, because Ms DTC is used as the transaction Coordinator for COM + Resource Manager/dispenser and Compensatingresource Manager, a single transaction can consist of some actions for resources, These resources can be any of the above structures. This feature makes compensating Resource manager one of the most attractive solutions to provide transactional access to resources.