In programming, you often need to use transactions. The so-called transaction is a series of operations that must be successful, as long as there is a step failure, all other steps must also be revoked. For example, use ASP to develop a network hard disk system, and its user's registration section is:
1. Make user information into the database
2, open a folder for the user to store
3, initialize the user's operation log
These three steps must be used in transactions, otherwise the disk operation failed, and without undoing the database operation, it will cause only "dead users" phenomenon that can only be landed without being able to operate.
Due to the special development history of the database system, small to Access, large to DB2, have no business support. Therefore, the above steps can be represented as follows:
ON Error ResMe next
first step:
Make user information in the transaction environment into the database
IF Err THEN
Shut down connection
drop out
Else
Step 2: Create a folder
IF Err THEN
Roll back the first step database operation, exit
Else
Step 3: Operation log database in the transaction environment
IF Err THEN
Roll back the first step, delete the two folder created
drop out
END IF
END IF
END IF
Submit a transaction for the first step database
Submit a second step database operation
End
Every step needs to be judged. If it fails, you need to manually return multiple steps in front, so that the program is complicated, it is difficult to understand. If the program is updated in the future, add additional steps, and need nesting more layers of IF ... Else ... END IF, making the program process more complicated.
The correct solution is to use the ASP's transaction control function. IIS passes through and the MTS service, you can control a system that supports transaction. When the program issues a "failed" signal, all systems that support transactions will automatically roll back, even if the operation is formally completed; do not support transaction operations It provides a convenient manual rollback method. The above example rewrites with the ASP transaction control function as follows:
<% @ Transaction = Required%> On Error Resume NextSet Conn = Server.createObject ("AdoDb.Connection") conn.open .... conn.execute "insert ...." Conn = NothingSet conn2 = Server .CreateObject ("adodb.connection") conn2.open .... conn2.execute "insert ...." conn2.closset conn2 = nothingset fso = server.createObject ("scripting.filesystemObject") fso.createfolder ". .. "If Err ThenObjectContext.SetAbort 'notification component support rolls back all transactions, and manual rollback operation codes ElseObjectContext.SetCompleteEnd IfSet FSO = NothingSub OnTransactionAbortResponse.Write" error "FSO.DeleteFile Server.Mappath (" a.txt ") 'FSO manual rollback - delete folder End subs onTransactionCommitresponse.write "Victory completed task" End Sub%>
The first line of <% @ Transaction = Required%> means this page ASP file requires MTS's transaction support. The various operations in the middle are written in ordinary order without considering rollback problems. In the final judgment, there is an error. If there is, call ObjectContext's setabort method, IIS will notify all component rollbacks (mainly databases) through the MTS service, and run Sub OntransactionAbort to hand-roll back to operations that do not support transactions; if no errors have occurred, call ObjectContext SetComplete method, run Sub OntransactionCommit to display successful messages. The entire ASP program does not need to write extra code for judgment errors and rollback operations, and only need to be judged, even in the future, it is only necessary to control in Sub Ontransactionabort, which is very convenient, programmers Focus on process writing rather than writing error correction code.
In fact, the ASP also provides a number of more useful features, waiting for us, don't think that ASP uses scripting languages, the function is so weak.
