The begin work statement starts a transaction.
begin {work|transaction} {name} {then|else statement.block}
| work | Optional and is provided only for SQL compatibility. |
| transaction | Optional and is provided only for SQL compatibility. |
| name | Name of the transaction. This name displays when using the TCL transaction utility status option to monitor transaction processing, or when the system is recovering after a halt. The name makes it easier to identify work-in-progress in these situations. |
A transaction is used to perform a series of updates to the database in an atomic manner. To begin the sequence, use the begin work statement followed by the desired updates. To commit the updates to the database, use the commit work statement. If a problem develops during the series of writes that prevent the correct completion of the transaction, use the rollback work statement to undo the changes.
Once a transaction is active, the variables below contain:
| Variable | Description |
|---|---|
| @transaction | This numeric value is nonzero when a transaction is active. |
| @transaction.ID | Current transaction.ID number, or zero if no transaction is active. |
| @transaction.name | If name is specified in the begin work statement, this variable contains that name. Null if no transaction is active. |
These operations perform differently in a transaction:
| execute | Executes a system command. No special checking is done on executed system-level commands, and no atomicity is asserted by the system. The programmer is responsible for assuring that all executed retrievals are atomic by performing the necessary filelock and readu statements before invoking execute. Updates performed by an executed system command do not participate in the transaction. These execute operations generate a run-time abort if attempted within a transaction: create-file, clear-file, delete-file, create-index, delete-index, and resize-file. |
| filelock |
For the FSI: Not Supported. Sets an exclusive lock on a file disallowing other users from updating or locking that file. It is necessary to execute this statement before an operation that can reference the file sequentially during a transaction. |
| fileunlock |
For the FSI: Not Supported. Releases a file lock. This statement is ignored during a transaction because all locks are held until the transaction completes. |
| key | Returns index information. This operation never participates in a transaction. Index entries are never updated until commit time, and no user-specific cache is provided. This means that it is invalid to access index entries for records that have been updated within a transaction before that transaction has been committed. Also, if strict transaction ordering is required, it is necessary to set a file lock prior to using the index. |
| read/readu | Reads a record. By default, this operation sees updates already made by the process, but not yet committed (unless transaction cache off has previously been run in the program). The readu command should always be used within a transaction to guarantee serialized schedules. Reads in a transaction operate at the read-committed isolation level. If another process updates an item that has been read within a transaction and the item is re-read within the transaction, then it will see the updated image. For repeatable read isolation, the readu command, or some other means, can lock the item so that subsequent reads in the transaction will see the same image. Using a readu command instead of a read command gives repeatable reads to the user. |
| readnext | Reads an item-ID from a select list. To use this validly within a transaction, each readnext must be followed by a read of the associated item-ID. This allows verification that the item has not been deleted within the transaction. Items that have been inserted within the transaction are returned by the readnext after all of the pre-transaction IDs are exhausted. |
| release | Releases item locks. You can use the release statement to release a
lock, even if it is under a transaction.
Warning: Be aware that in
releasing locks during a transaction, that other processes can then modify those
items which may have a negative effect on your transaction.
|
| select | Selects a list of items. To enforce transactions that are serialized, the user must lock the specified file before performing the select. If the select list is based on a prior execute, then the filelock must be performed prior to that execute. |
| write | Writes a record. This operation always participates in the transaction (that is, the effects of the write, including the release of any associated locks, are not committed to the database until the commit). The same rule applies to all variants of the write (writeu, writev, writevu, matwrite, and matwriteu). |
| stop | Stops the program. If a transaction is active, then the stop statement or any other condition that terminates the program causes the equivalent of a rollback to occur. |
The system-coldstart procedure automatically rolls backward any pre-commit transactions and rolls-forward (if possible) any post-commit transactions if the system halts unexpectedly.
These features are not currently supported within a transaction:
For the FSI: BASIC Transaction Bracketing is supported in Flash only.
For the VME: BASIC Transaction Bracketing is supported in both nonFlash and Flash. Operations on OSFI files can be included in a transaction. However, in the event of recovery from a system failure (rollback or roll forward) those operations will be ignored because the file handles to the remote files will no longer be valid.
abort statement, clearfile statement, commit work statement, create-index command, delete-file command, delete-index command, execute statement (UNIX), filelock statement, fileunlock statement, matwrite statement, read statement, readnext statement, readv statement, rollback work statement, nselect command, stop statement, transaction cache statement, transaction flush statement, transaction start function, transaction statement, transaction utility, write statement, writeu statement, writev statement, _CP_trans