COM + transactions and IIS

Iis

Microsoft has tightly integrated the capabilities of IIS and COM +, which makes it very easy to leverage transactional applications in the process of programming the transaction Web page. There are many different ways to integrate the transaction characteristics of COM + and IIS, including the following:
? Transactional ASP.
? The ObjectContext in ASP.
? Transactional events.
Developers can use one or more of these features in applications that use IIS and COM +. Because they are tightly integrated, developers can make full use of these services by doing only a small amount of work. In fact, ObjectContext encapsulates a transaction in COM + that can be used directly in an ASP page in a transaction.
19.4.1 Transactional ASP
Because of the integration of IIS 4.0 and MTS, developers can include ASP scripts in a single transaction. These ASP pages can contain calls to server components that will also participate in the same transaction. As with all transactions, if any part of a transaction fails, the entire transaction is rolled back. The added advantage of transactional ASP scripts is that it makes it simpler to bind multiple components to a single transaction.
There is a problem with transactional scripting when dealing with a terminated transaction. Changes that are generated by accessing the database through the resource manager of the database are automatically rolled back, however, COM + cannot roll back the changes that the script itself produces. For example, any changes that are produced by using a script, such as a change to a session or application variable, will not be automatically rolled back. Later you will see how to use transactional event notification that a transaction has terminated. When handling this event, the master site rolls back changes that COM + cannot automatically roll back. This limitation is due to the fact that COM + transactions can only roll back changes that are produced by services that are compatible with MS DTC.
There is a new feature in IIS 5.0. Developers have the ability to make a transaction span multiple ASP script pages. This is due to the new execute and Transfer methods on the server object.
However, normally, all processing of a single transaction can be done in a single ASP Web page. For example, if an application has a component that withdraws from one account and another component deposits in one account. To transfer funds from one account to another, create an ASP script, withdraw funds from an account using the withdrawal component, and deposit funds into a new account using a savings component. Put all of these features into a transactional ASP Web page, and if any part of the transaction fails, roll back all changes and the account balances back to their initial values.
To declare a Web page to be transactional, use the following directives:
<%@ Transaction=value%>
The possible settings for the transaction directive are:
? Disabled: Tell COM + that you do not want to involve components in a transaction.
? Requires_new: A new transaction is started even if a transaction already exists.
? Required: Start a new one if there is no transaction, and participate in it if it exists.
? Supported: Does not start a transaction, but participates in it if the transaction already exists.
? Not_supported: does not participate in a transaction even if there is a transaction.
These values are the same as the transaction support properties that are set for each component using the Component Services browser.
The transaction instruction must be in the first line of the ASP page script, usually contained by the language instruction. If there is anything before this on the page, a script error is generated. As with transactions in an assembly, if the last line of code is reached and has not yet been committed or terminated, COM + assumes the commit and writes the changes to disk. In addition, each object called by the page can participate in the transaction using the ObjectContext object of the same ASP page, which is usually done.
19.4.2 ObjectContext objects in transactional ASP
When writing a transactional ASP script, you may want to directly affect the outcome of the script's transaction. Like the components that are written for transactions, ASP pages can also take advantage of ObjectContext objects. Since the publication of ASP 2.0, this object can be used to provide functionality for all transaction routines that developers need. This is the object that the server component accesses when it participates in the transaction, which contains the SetAbort and SetComplete methods.
The following code shows how to instantiate two COM objects and one transaction on a transactional Web page and invoke a method on both objects.
Note that the transaction settings at the top of the page indicate that a transaction is requested. It is this setting that makes the page participate in the same transaction as a COM component. In fact, as long as the COM component's transaction support property is required or supported, they become part of the transaction initiated by the ASP page.


As an ASP page executes, a method of calling each COM class is invoked. When each method is executed, its return value is used to determine whether the processing was successful. If either method returns a value other than 0, the ASP page works. Otherwise, the ASP page commits the transaction and stores the changes in the disk.
The point of this example is that all method calls are rolled back into the same transaction as the ASP page invokes the SetAbort method in the ObjectContext object.
The above example can also be rewritten so that methods in the COM component are invoked from within the SetComplete and SetAbort methods. This removes some logic from the ASP page and embeds it in the COM component. The only problem with writing transactions in this way is that the ASP page does not know whether to commit or terminate the transaction. However, this can be resolved by implementing transaction events.
19.4.3 Transaction Events
ASP pages also have the ability to listen to COM + to see when transactions will be committed or terminated. This is done by calling two routines by IIS before COM + commits or terminates a transaction. These two methods are called O Transaction commit and on Transactionabort.
The OnTransactionCommit method is triggered before COM + commits a transaction, and after the preparation phase. The OnTransactionCommit routine (event) is triggered and the transaction is committed as long as there are no partial terminations in the transaction. If the transaction is terminated, the OnTransactionAbort event is triggered:

As with most transactional ASP pages, the example above begins by declaring that it requires a transaction, and then the script calls a method of a transactional COM object. Once the page is completed, COM + will determine the outcome of the transaction by checking whether there is a part of the transaction that calls the SetAbort method. If the SetAbort method is not invoked, the OnTransactionCommit event is triggered and the transaction is committed, and if the SetAbort method is invoked, the OnTransactionAbort event is triggered and the transaction is rolled back.