|
|
|
There may be situations where you do not want to commit the transaction. Rather, you will want to throw the whole thing out as if it never took place. For instance, you are taking a customer order over the telephone, updating the files as the customer requests certain items. However, the customer decides that the order should not be placed at all, and cancels out. Without transaction processing, you would be faced with the difficult process of going back and reversing out all of the updates that you have done. Alternately, you could build your system so that you don’t actually do the updates, you just keep them in a temporary file. This can also be a problem, as you are not able to place a commitment on a particular inventory item, and when you actually decide to place the order you may find that the items you promised were consumed by another order.
Abort and AbortXtd
This process is made simple by transaction processing. Start the order with a Begin() call, process the order details as you go, and issue a Commit() call to commit the updates when the customer decides to place the order. However, if the customer decides to back out, you can use the Abort() call to abort the transaction. This will abort all of the file updates since the last call to Begin(), as well as releasing all locks. Abort() can be used whether Begin() uses the ctPREIMG or ctTRNLOG mode.
Note: Starting a transaction in an interactive mode will cause long held locks on those items updated, but not yet committed.
Changes in V11.5
Note: This is a Compatibility Change.
When aborting a transaction on the master server failed, we previously returned immediately rather than aborting the transaction on the local server. Now, in this situation, we mark the master server transaction as no longer active and then we abort the local transaction.
When phase 1 of the master server commit fails, we did not reset the active transaction indicator for the master server. This caused us to believe that the transaction on the master server was still active, even though it was not. Now we properly reset the active transaction indicator in this situation.
