begin work statement

The begin work statement starts a transaction.

Syntax

 begin {work|transaction} {name} {then|else statement.block}

Parameter(s)

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.

Description

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.
Note: Nested transactions are not allowed and cause the begin work statement to fail.

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.

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.

BASIC Transaction Bracketing

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.