ASP lecture series (21) Creating transactional scripts
Author：Eve Cole
Update Time：2009-05-30 19:58:32
Business applications often require the ability to run scripts and components inside transactions. A transaction is a server operation. Even if the operation includes many steps (for example, ordering, checking inventory, paying bills, etc.), it can only return the overall success or failure of the operation. Users can create ASP scripts that run inside a transaction. If any part of the script fails, the entire transaction will terminate.
ASP transaction processing is based on Microsoft Transaction Server (MTS). Microsoft Transaction Server (MTS) is a transaction processing system for developing, configuring, and managing high-performance, scalable, and robust enterprise Internet and Intranet server applications. Transaction Server provides an application design model for developing distributed, component-based applications. It also provides a runtime environment for configuring and managing these applications.
The ability to create transactional scripts is built into Internet Information Server and Personal Web Server. If you have Microsoft Transaction Server installed, you can package components so that they run inside a transaction.
About Transactions A transaction is the overall success or failure of an operation. Transaction processing is used to reliably update the database. When making many related changes to a database or updating multiple databases simultaneously, ensure that all changes are executed correctly. If any of these changes fail, the original state of the database tables needs to be restored.
Without MTS, you would need to write scripts and components to manually track requested changes in order to recover the data if some changes failed. Using MTS, you simply declare your scripts and components as "requiring transactions" and let MTS handle transactional consistency. Transaction processing only applies to database access; MTS cannot recover changes to the file system or other non-transactional resources. The database accessed by the application must be supported by MTS. Currently, MTS supports SQL Server and any server that supports the XA protocol (specified by the X/Open Association). MTS will continue to expand support for other databases.
Transactions cannot span multiple ASP pages. If a transaction requires objects from multiple components, the operations that use these objects must be combined in an ASP page. For example, assume you have a component that updates a payroll database and a component that updates employee records in a human resources database. In order to record new salary information for an employee, you need to write a script that calls these two components in a transaction context, one to update the payroll database and the other to update the employee grade in the human resources database. .
Declaring transactional scripts When you declare a page as transactional, any script commands and objects in the page run in the same transaction environment. Transaction Server handles the details of generating transactions and determines whether the transaction succeeds (commits) or fails (terminates). To declare a page as transactional, add the @TRANSACTION directive at the top of the page:
<%@ TRANSACTION = value %>
The value parameter can be one of the following:
value meaning
Requires_New starts a new transaction.
Required starts a new transaction.
Supported does not start a transaction.
Not_Supported Does not start the transaction.
The @TRANSACTION directive must be on the first line of a page, otherwise an error will be generated. This directive must be added to every page that needs to run under a transaction. When script processing ends, the current transaction ends.
Most applications require a transaction environment only for certain operations. For example, an airline site might only require transactional scripts to handle ticketing and seating arrangements, while all other scripts can run securely without a transactional environment. Because transactions only need to be used for pages that require transaction processing, do not declare your application's Global.asa file to be transactional.
If a transaction is aborted, Transaction Server reverts any changes to transaction-backed resources. Currently, only database servers fully support transactions because the data in the database is most critical for enterprise applications. Transaction Server does not restore changes to files, session and application variables, collections, etc. on the hard disk. However, you can script restoration of variables and collections by writing transaction events, as described in the following topic. At certain times, your script can also explicitly commit or terminate a transaction, such as when writing data to a file fails.
Commit or terminate scripts Because Transaction Server keeps track of transaction processing, it determines whether the transaction completely succeeded or failed. A script can explicitly terminate a transaction by calling ObjectContext.SetAbort. For example, a script needs to terminate a transaction when it receives an error message from a component, violates business specifications (for example, an account balance is less than 0), or fails for non-transactional operations such as reading and writing files. If the page times out before the transaction is completed, the transaction must also be terminated.
Writing transaction event scripts alone does not determine whether a transaction succeeds or fails. However, you can write events that are called when a transaction is committed or terminated. For example, if you have a script that confirms a bank account, and you need to return different pages to the user for different states of the transaction, you can use the OnTransactionCommit and OnTransactionAbort events to write different responses to the user.
<%@ TRANSACTION = Required %>
<%
'Buffer output so that different pages can be displayed.
Response.Buffer = True
%>
<HTML>
<BODY>
<H1>Welcome to the online banking service</H1>
<%
Set BankAction = Server.CreateObject("MyExample.BankComponent")
BankAction.Deposit(Request("AcctNum"))
%>
<P>Thank you. Your transaction is being processed.</P>
</BODY>
</HTML>
<%
' Display this page if the transaction succeeds.
SubOnTransactionCommit()
Response.Write "<HTML>"
Response.Write "<BODY>"
Response.Write "Thank you. Your account has been credited."
Response.Write "</BODY>"
Response.Write "</HTML>"
Response.Flush()
end sub
%>
<%
' Display this page if the transaction fails.
SubOnTransactionAbort()
Response.Clear()
Response.Write "<HTML>"
Response.Write "<BODY>"
Response.Write "We are unable to complete your transaction."
Response.Write "</BODY>"
Response.Write "</HTML>"
Response.Flush()
End sub
%>
Registering a Component in the MTS Resource Manager In order to participate in a transaction, the component must be registered in the MTS package and must be configured to require transactions. For example, if your script handles orders by calling two components, one updates the inventory database and the other updates the payments database. Then, these two components must run in the same transaction environment. Transaction Server guarantees that if any component fails, no database will be updated. Some components do not require transactions; for example, the Ad Rotator component.
Register and configure transactional components using MTS Resource Manager. The transaction's properties must be set to Require Transaction or Require New Transaction. Transaction components must be registered in the MTS package. Rather than placing components in IIS in-process packages, create your own packages. Typically, all components should be placed in a component library. The components of the component library can be used by multiple ASP applications and run in the ASP application process. Use MTS Explorer to create a new package and set the package's Activation property to Library.
Transactional components can also be registered in the Server package. Server packages usually run as a separate process on the server. If you want to use functional group-based security checking or if you want your components to be accessible to applications on remote computers, use the Server package for transactional components.
To use MTS Explorer, Microsoft Transaction Server must be installed.
Object Scope In general, do not store objects created from MTS components in ASP Application or Session objects. MTS objects disappear after the transaction is completed. Because the Session object and Application object are designed for object instances used between different ASP pages, do not use them to store objects that are released at the end of a transaction.
The ASP script is the root of the declared transaction, the starting point. Any MTS object used by a transactional ASP page is considered part of the transaction. When the transaction is completed, the MTS objects used in the page will disappear, including objects stored in the Session or Application object. After this point, any attempt to call a session-scoped or application-scoped object from another transactional page will fail.
Transaction queuing Updates to a database from a remote server can cause transactions to be delayed or terminated due to network delays or failures. Because all parts of the transaction must commit, the application may hang, waiting for a commit or abort message from the remote server, or the transaction may be aborted because database updates cannot be sent.
For updates that must complete simultaneously, the correct approach is to terminate the transaction or delay completion of the transaction until all participants in the transaction are able to commit. For example, an airline's booking process should simultaneously debit the customer's bank account and credit the airline's bank account. If an update is part of an overall transaction, but may be later than other updates, you may not want to make the customer wait for the entire update process to complete. For example, a flight booking transaction might also send a food order to a food supplier or update a customer's travel allowance. Although these operations must be completed, they can be done later.
Microsoft Message Queue Server enables you to bundle an update or a set of updates into a transactional message to a remote server. Message Queue Server guarantees that updates will be sent to the remote server even if the network is currently unavailable. Your app will receive a commit message and can continue processing the transaction.
