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 been run in the program previously). The readu form should always be used within a transaction to guarantee serialized schedules. |
| 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. This operation is ignored during a transaction because all locks are held until commit or rollback. |
| 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:
Using bridge correlatives.
Using remote (distributed) files.
Using non-D3 files.
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 may be included in a transaction, but 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