- Creating Transactional Web Pages
- Creating Multipage Transactions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Creating Multipage Transactions
IIS 4 supported only single-page transactions. Under IIS 5, however, you can now create transactions that span the work performed by multiple ASP pages. This is accomplished by using two new methods of the Server object: Execute and Transfer. Both methods allow one ASP page to call another without returning any information to the client browser. This is an important distinction because ASP transactions always appear to be a single Web page request from the browser's perspective, even if many ASP pages are involved.
The Execute method is simple to understand because it behaves like a function call. When you use the Execute method, the targeted ASP page is called and any server-side script found there is executed. After the code is executed, control returns to the original page.
The Transfer method transfers processing to a new ASP page in a manner similar to the Redirect method. The difference is that a Redirect actually requires a round trip to the client before control is transferred. With the Transfer method, all variables and submitted data are made available without a round trip. The Transfer method also doesn't return control to the original page after processing is complete.
Regardless of which method you use, you can still enlist multiple pages in a transaction by using the @TRANSACTION directive. The page initially called by the client browser can be designated as REQUIRES_NEW, and subsequent pages called by Transfer or Execute can be designated as REQUIRED. This means that the work done by all the pages will be part of the same transaction.
Consider an example in which we want two pages to work together in a transaction. The first page initiates the transaction and performs some work. Then that page enlists a second page in the transaction through either the Transfer or the Execute method. The code in Listing 2 shows the first page using the Execute method.
Listing 2 Starting a New Transaction
<%@Transaction="Requires_New" Language=VBScript %>
<%Option Explicit%>
<HTML>
<BODY>
<H1>First, we start a transaction</H1>
<%Server.Execute "work.asp"%>
<H1>Control returns to the first page</H1>
<%
Sub OnTransactionCommit
Response.Write _
"<H1>Then we commit the transaction</H1></BODY></HTML>"
End Sub
Sub OnTransactionAbort
Response.Write _
"<H1>Then we abort the transaction</H1></BODY></HTML>"
End Sub
%>
When multiple pages are involved in a transaction, the output buffer isn't flushed until all the pages have done their work. This means that any calls to Response.Write are cumulative in the transaction process. Therefore, we don't need to include most of the HTML tags in subsequent calls.
The code in Listing 3 shows a page that can be enlisted in a transaction.
Listing 3 Enlisting a Page in a Transaction
<%@Transaction="Required" Language=VBScript %>
<%Option Explicit%>
<H1>Then we perform work in another page</H1>
<%
Sub OnTransactionCommit
Response.Write "<H1>The page votes to commit</H1>"
End Sub
Sub OnTransactionAbort
Response.Write "<H1>The page votes to abort</H1>"
End Sub
%>
Calling the first page in the example from our browser builds a response page that combines the output of both pages. Also note that each page can have its own set of OnTransactionCommit and OnTransactionAbort routines, which are executed for each page in the transaction.
If you modify the first page to call the second using the Transfer method, control won't generally return to the original page. This means that the second page can have increased responsibility to format the output. The only exception to this rule is if the original page has coded OnTransactionCommit and OnTransactionAbort routines. In this case, the appropriate routine will be executed when the final transaction commits or aborts.