There is no method for an ASP script to explicitly determine if a transaction that it is participating in has aborted or committed. As shown in the previous example, it can examine the return values of methods that it calls. But unless those methods provide indication in their return values that they have called SetComplete or SetAbort, there is no other indication of the transaction's state.
The ASP script can use transaction events to perform special processing if a transaction is being committed or being aborted and rolled back. The firing of the events cause methods of the ObjectContext object to be executed. The ObjectContext object provides two methods that the ASP script can handle. The OnTransactionCommit method is fired if the current transaction is successful. Since the transaction is not committed until after the script reaches the end, then this event will be not be fired until the entire page has been processed. The OnTransactionAbort method is called if the current transaction is being aborted. The method will be called immediately after any object participating in the transaction calls SetAbort.
Let's take a look at an example of how to use transactional events to provide a response if a transaction fails or succeeds.
<%@ TRANSACTION = Required %>
<HTML>
<BODY>
<H1>Completing your order…</H1>
<%
dim iOrderNum
Set objCredit = Server.CreateObject("BookComp.Credit")
curOrderTotal = Request("OrderTotal")
CustomerID = Request("CustID")
iOrderNum = objCredit.ProcessCredit(curOrderTotal, CustomerID)
%>The ASP script up to this point has basically the same structure as the one we looked at in the previous section. Values are passed into this script using a Form. A reference to a server component is created, and then a method of that server component is called. The value that the server component returns is the order number.
The difference comes about in that the ASP script does not immediately check for the return value. It merely gives the user an indication that the transaction is being processed. Since the Buffer property of the Response object is set to its default, which is false, this information will be displayed immediately on the client. The client is informed of the success or failure of the transaction through the use of transactional scripts.
<P>Thank you. Your transaction is being processed.</P>
<%
Sub OnTransactionCommit()
Response.Write("<P>Thank you for placing your order.</P>")
Response.Write("<P>Your order number is "& CStr(iOrderNum) & ".</P>")
Response.Write("</BODY></HTML>")
End sub
If the transaction is successful, then the OnTransactionCommit method is called. This displays a message to the client indicating a successful order. The order number that is returned from the server component method is also displayed for the user.
If there is a failure somewhere in the transaction, the OnTransactionAbort method will be called. This message displays an indication on the client that the transaction was unsuccessful. Any changes to durable data that were made in the server component will be automatically rolled back. If there was any ASP session or application data that was changed in the transaction, those changes can be rolled back at this point. Since ASP does not provide for automatic rollback of changes made via ASP script, the code to support the rollback will need to be explicitly written, which is not shown in this example. The OnTransactionAbort method is the ideal place to reference that code from.
Sub OnTransactionAbort()
Response.Write("<P>An error has occurred in processing your order</P>")
Response.Write("<P>We are unable to complete it at this time.</P>")
Response.Write("</BODY></HTML>")
End sub
%>Now that we are able to handle transaction events, which give us the ability to determine if a transaction is successful or not, we can take a look at some of the other advantages that the integration of IIS and MTS provide. One of these is the "crash protection" that MTS provides for IIS and ASP applications.