Transaction Processing

In this COBOL system, transaction processing is only available if you are using Fileshare but Btrieve users do not require Fileshare to implement transaction processing.

When you update records in a file in a transaction with Fileshare, the individual records in the file are locked to prevent another user from reading the record. This is because there is the possibility of a ROLLBACK operation being performed when a record has been removed from the file. However, when you access a Btrieve file via Xfh2btr from a transaction, the whole file is given a temporary exclusive file lock which prevents other users from accessing the file at the same time. In Btrieve v6.x and later, concurrent transactions are used, so files can be shared in a transaction.

A Btrieve transaction starts whenever a REWRITE, WRITE or DELETE operation is performed for a file that has no transaction in progress and has been opened with ROLLBACK. At this point, Btrieve obtains an exclusive lock on the file and this file lock remains until the transaction finishes, except when concurrent transactions are in use (Btrieve v6.x and later).

Note: Notes:
  • For Btrieve v6.x or above, concurrent Btrieve transactions are used. Btrieve then performs locking at the page level. (See the Btrieve documentation for details.)
  • A transaction finishes when a COMMIT or ROLLBACK operation is performed. The transaction restarts when I/O is performed again on a file which is opened with ROLLBACK.

The CLOSE operation does not re-start transactions because Btrieve CLOSE operations can only be performed when transactions are not active.

File-locked errors are returned by Xfh2btr at the time files are opened, as this is the only time that this COBOL system returns a file-locked error. Btrieve can return a file-locked error on accessing a file in a transaction, although this is converted to a record-locked error by Xfh2btr which is a status that could legitimately be returned by this COBOL system when accessing files in transactions.