Create | Scripting business applications often need to have the ability to run scripts and components within a transaction. A transaction is a server operation that, even if it involves many steps (for example, ordering, viewing inventory, paying bills, and so on), can only return the success or failure of the operation as a whole. A user can create an ASP script that runs inside a transaction, and the entire transaction terminates if any part of the script fails.
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 running environment for configuring and managing these applications.
The ability to create transactional scripts is built into the Internet Information Server and Personal Web server. If you have installed Microsoft Transaction Server, you can package the components so that the components run within the transaction.
About transactions
A transaction is an overall success or failure operation. Transaction processing is used to reliably update the database. Make sure that all changes are performed correctly when you make many related changes to the database or when you update multiple databases simultaneously. If any of these changes fail, you need to restore the original state of the database table.
Without MTS, you would need to write scripts and components to manually track changes to the request to recover the data if some of the changes fail. With MTS, you simply declare your scripts and components as "need transactions" and let MTS process the consistency of transactions. Transactions apply only to database access, and MTS cannot recover from changes to file systems or other non-transactional resources. The database accessed by the application must be supported by MTS. Currently, MTS supports SQL Server and any servers that support the XA protocol (developed by the X/open Association). MTS will continue to expand its support for other databases.
Transactions cannot span multiple ASP pages. If a transaction requires objects from more than one component, you must combine the operations that use these objects into an ASP page. For example, suppose a component is used to update payroll databases, and a component is used to update employee records in the human resources database. To record the new payroll information for an employee, you need to write a script that calls both components in a transactional environment, one for updating payroll databases, and another for updating employee levels in the human resources database.
Declaring a transactional script
When you declare a page as transactional, any script commands and objects in this page run in the same transaction environment. The Transaction Server processes the details of the generated transaction and determines whether the transaction succeeds (commits) or fails (terminates). To declare a page as transactional, you can add a @TRANSACTION directive at the top of the page:
The value parameter can be one of the following:
Value meaning
Requires_new to start a new transaction.
Required to start a new transaction.
Supported does not start a transaction.
Not_supported does not start a transaction.
@TRANSACTION instruction must be on the first line of a page, or an error will occur. You must add the directive to every page that you want to run under a transaction. The current transaction ends when the script is processed.
Most applications have only a few specific operations that require a transactional environment. For example, an airline's site might require only transactional scripting to handle ticketing and seating, while all other scripts would run safely without a transactional environment. Because transactions only need to be used for pages that require transactions, do not declare the application's Global.asa file as transactional.
If the transaction is terminated, Transaction Server restores any changes to the resources that support the transaction. Currently, only the database server fully supports transactions, because the data in the database is most critical for enterprise applications. Transaction Server does not restore changes to files, sessions, and application variables, collections, and so on on your hard disk. However, you can write a script for recovery variables and collections by writing transaction events as described in the following topic. At some point, your script can also explicitly commit or terminate a transaction, such as failing to write data to a file.
Commit or Terminate script
Because Transaction Server tracks transactions, it determines whether the transaction succeeds or fails. The script can explicitly declare the termination of a transaction by calling ObjectContext.SetAbort. For example, when a transaction fails with a transactional operation that receives an error message from one component, violates a business specification (for example, an account balance of less than 0), or a read-write file, the script needs to terminate the transaction. If the page times out before the transaction completes, the transaction must also be terminated.
Writing transaction Events
The script itself cannot determine whether a transaction succeeds or fails. However, you can write events that are invoked when a transaction is committed or terminated. For example, suppose you have a script that confirms your 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 a different response to the user.
Welcome to the Online banking service
Thank you. Your transaction is being processed.
Registering a component in the MTS resource Manager
In order to participate in a transaction, the component must be enlisted in the MTS package and must be configured to require transactions. For example, if your script is to process an order by calling two components, one updates the inventory database, and the other updates the payment database. Then, the two components will run in the same transaction environment. Transaction Server guarantees that if any one component fails, no database will be updated. Some components do not require transactions; For example, the Ad Rotator component.
You can use MTS Resource Manager to register and configure transactional components. You must set the properties of the transaction to require a transaction or require a new transaction. The transaction component must be registered in the MTS package. Instead of placing components in the IIS internal process package, you should create your own packages. In general, all components should be placed in a component library. Component library components can be used by multiple ASP applications and run as ASP application processes. Use the MTS Explorer to create a new package and set the activation property of the package to the Library.
You can also register transactional components in the Server package. The server package is typically run as a separate process on the server. You can use the Server package for transactional components if you want to use a security check that is based on a functional group or if you want your component to be accessible to applications on a remote computer.
To use MTS Explorer, you must install Microsoft Transaction Server.
Object Scopes
In general, do not store objects created from an MTS component in an ASP application or a Session object. The MTS object disappears after the transaction completes. Because the session object and the Application object are designed for object instances that are used between different ASP pages, do not use them to save objects that are disposed at the end of a transaction.
ASP script is the root of a known transaction, the starting point. The MTS objects used by any transactional ASP page are considered to be part of the transaction. When the transaction completes, the MTS object that is used in the page disappears, including the objects stored in the session or Application object. After this, attempts to invoke the session scope or application scope object from another transactional page will fail.
Transaction queuing
Updates to the database from one remote server may cause a transaction delay or termination due to a network delay or failure. Because all parts of a transaction must be committed, the application may hang, wait for a commit or terminate message from the remote server, or it may cause the transaction to be discarded because the database update cannot be sent.
For updates that must be completed at the same time, the correct approach is to terminate the transaction or postpone the completion of the transaction before all the participants in the transaction can commit. For example, the airline's booking procedure should also complete the debit of the customer's bank account number and the credit for the airline's bank account. If an update is part of a transaction as a whole, but may be later than other updates, you may not want the customer to wait for the entire update process to complete. For example, a ticket booking transaction may also send a food order to a food supplier or update a customer's travel allowance. These operations must also be completed, but can be later.
Microsoft Message Queue Server enables you to bundle one or a set of updates to a transactional message to a remote server. Message Queue Server guarantees that updates will be sent to the remote server, even if the current network is not available. Your application will receive a submit message so that you can proceed with the transaction.
