Transaction processing enables you to group a set of data file updates together into one logical unit of work, known as a transaction.
The changes you make as part of a transaction can be:
- Permanently reflected in the data files by committing the work
- Removed from the data files by rolling back the work. When a transaction is rolled back, the Fileshare Server returns the data files to the state they were in before the transaction started.
A transaction can include multiple updates to multiple data files on multiple Fileshare Servers.
A transaction starts when your program performs the first update operation (WRITE, REWRITE or DELETE) on a file which has the WITH ROLLBACK clause defined in its SELECT statement after:
- The file is opened
- A COMMIT or ROLLBACK statement is executed
A transaction terminates when:
- A COMMIT verb is executed
- A ROLLBACK verb is executed
- The transaction is timed out. See the section
Automatic Record Lock Timeout for further information.
Notes:
- The COMMIT and ROLLBACK verbs release all the record locks held by a program on every data file. This does not depend on whether or not you specified the WITH ROLLBACK clause for a particular file.
- The time taken to process a COMMIT or ROLLBACK operation is directly proportional to the number of updates performed in that transaction.
- If you try to CLOSE a file that is participating in an active transaction, a 9/100 error status is returned and the file remains open. A COMMIT or ROLLBACK needs to be issued before the CLOSE can be executed.
- When you use the WITH ROLLBACK clause, multiple record locking is implicitly defined on the file.
Before using transaction processing you are strongly advised to do the following to ensure the highest level of integrity for your data:
- Include any file on which transaction processing is to be performed in the database reference file of the Fileshare Server that services the I/O requests for that file. See the section
Database Reference File Maintenance for further information.
- Specify a rollforward recovery log file in the database reference file. See the section
Rollforward Recovery Logging for further information.
Record locks are implicitly obtained on every record that is updated in a transaction. If a transaction is temporarily suspended, for example, if your program requests input and the user is not responding, record locks can remain in the file for a considerable length of time. If another Fileshare Client tries to access the locked records, and a specified length of time has passed, the Fileshare Server aborts (rolls back) the transaction. When this happens, the transaction is said to be timed out by the Fileshare Server. See the section
Automatic Record Lock Timeout for further information.
Note:
By keeping the number of updates performed in a transaction to a minimum, the number of record locks obtained is also kept to a minimum. This reduces the number of record locking conflicts between Fileshare Clients sharing the data, and increases the speed of any subsequent COMMIT or ROLLBACK operations.
