Data recovery

Overview

If hardware or software failures occur during the process of updating Model 204 files, database integrity problems can arise. These problems result from the fact that updates to a file can require coordinated changes, and a failure can interrupt the process of writing to storage a complete set of these changes.

Normally in a Model 204 installation, the system manager is responsible for the coordination of recovery activity for the installation, and the file manager determines which recovery features are applied to each of the files.

For a complete description of the Model 204 recovery process, refer to the Rocket Model 204 File Manager's Guide.

Transaction back out

One of the recovery features that can be selected by the file manager is an integrity facility called transaction backout. This facility can reverse the effects of an incomplete transaction (a sequence of file updating operations).

Application considerations

Although the file manager determines whether the transaction backout facility is defined for a file, the application designer must understand the facility's capabilities and requirements in order to ensure file integrity for an application.

This chapter explains those capabilities and requirements and describes how applications can be designed to ensure file integrity. In particular, see the last section in this chapter for application design considerations.

Transaction backout

The transaction backout facility allows Model 204 to logically reverse the effects of an incomplete update to a file.

A backout can be initiated only on incomplete update units; completed update units cannot be backed out. A backout can be automatically performed by Model 204 or initiated by the user.

FOPT and FRCVOPT parameters

Transaction backout is an option of the FOPT and FRCVOPT parameters and is enabled or disabled on a file-by-file basis. Refer to the Rocket Model 204 Parameter and Command Reference Manual for more information on these parameters.

Types of backout

You can use the transaction backout facility to specify two types of files:

backout file types	File options set to...	Discussion
Transaction backout	Enable both lock pending updates and backout.	A transaction can be backed out automatically by Model 204 or manually by the application. A transaction backout file ensures: Logical consistency Data and file integrity, High degree of data sharing.
Non-transaction backout	Disable transaction backout.	Incomplete updates cannot be automatically reversed. Non-transaction backout files cannot be accessed remotely. Attempts to open a non-transaction backout file in remote context fails and generates the following error message: M204.1973: NON-TBO REMOTE FILE

Update units

An update unit is any sequence of operations that updates the database and that has a beginning and ending point. One update unit must end before another update unit can begin.

A request or procedure can have two types of update units:

Update unit type	Discussion
Backoutable	A backoutable unit consists of updates to transaction backout files using file updating statements (such as STORE RECORD). The unit can either be completed so that it persists in the file, or backed out so that the update is logically reversed in the file.
Non-backoutable	A non-backoutable unit consists of updates to non-transaction backout files.

Backoutable units

Beginning a backoutable unit

A backoutable unit begins at the execution of the first User Language statement that performs an update operation on a transaction backout file. The statements that perform update operations are:

• ADD fieldname = value
• CHANGE fieldname TO value
• DELETE EACH fieldname
• DELETE fieldname [= value]
• DELETE RECORD
• DELETE RECORDS
• FILE RECORDS
• INSERT fieldname = value
• STORE RECORD

Ending a backoutable unit

A backoutable unit ends when the unit is committed by using the COMMIT statement or is backed out. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this chapter) also can end an active update unit. Refer to the Rocket Model 204 File Manager's Guide for a complete list of conditions that end an active update unit.

Non-backoutable units

Beginning a non-backoutable unit

A non-backoutable unit begins with the first User Language statement that performs an update operation on a non-transaction backout file.

Ending a non-backoutable unit

A non-backoutable unit ends when the unit is committed by using the COMMIT statement. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this chapter) also can end an active update unit. Refer to the Rocket Model 204 File Manager's Guide for a complete list of conditions that start or end an active update unit.

Using backout

The transaction backout facility performs two types of backouts:

Backout type	Invoked...
Automatic	Automatically by a request cancellation An attention or *CANCEL command without an ON ATTENTION unit File full condition User restart.
Manual	Using the BACKOUT statement within a request.

Automatic backout

Model 204 automatically backs out the current update unit for a transaction backout file under any of the following conditions:

• If a request is cancelled by Model 204
• If there is a file integrity problem
• If Model 204 is restarting a user who has an active update unit

When a request accessing a transaction backout file is cancelled, the following events occur:

• The user receives a message that explains why the request was cancelled.
• The current update unit is backed out automatically.
• Model 204 returns to the terminal command level unless an ON ERROR or ON ATTENTION unit is invoked.

Remote updates are backed out automatically when appropriate.

Manual backout

You can backout an incomplete update unit by using the BACKOUT statement. This statement is valid only for updates to transaction backout files.

The BACKOUT statement releases the exclusive lock on updated records and backs out the current update unit. No found sets are released and the current record does not change.

After the BACKOUT statement is processed, evaluation continues with the next statement. A message is displayed to the user upon the successful completion of a backout operation.

The BACKOUT statement is supported in remote context. If records on any remote nodes have been updated, the BACKOUT statement causes all remote updates on all remote nodes to be backed out, in addition to any local updates.

Example

The BACKOUT statement is typically used in data entry applications where a transaction might have to be backed out after it has updated a file (for example, a sales or airline reservations application).

An example of a request that uses the BACKOUT statement is provided below.

BEGIN * * DECREMENT INVENTORY BEFORE MAKING SALE TO CUSTOMER * DECLARE %INPUT STRING LEN 70 DECLARE %VINTNER STRING LEN 30 DECLARE %SELECTION STRING LEN 40 * * ENTER PURCHASER'S SELECTION * GETVAL: %INPUT=$READ('ENTER VINTNER/SELECTION:') IF %INPUT EQ 'QUIT' THEN STOP END IF %VINTNER=$SUBSTR(%INPUT,1,$INDEX(%INPUT,'/')-1) %SELECTION=$SUBSTR(%INPUT,$INDEX(%INPUT,'/')+1) FDVINTNER: FD REC=VINTNER AND NAME=%VINTNER CTVINTNER: COUNT RECORDS IN FDVINTNER IF COUNT IN CTVINTNER EQ '0' THEN PRINT 'VINTNER DOES NOT EXIST TRY AGAIN' JUMP TO GETVAL END IF * * IF SELECTION EXISTS THEN UPDATE RECORD BY DECREASING * THE AMOUNT ON HAND * CTSELECTION: FOR EACH RECORD IN FDVINTNER FEOSELECT: FOR EACH OCCURRENCE OF SELECTION IF SELECTION(OCCURRENCE IN FEOSELECT) EQ - %SELECTION THEN %ONHAND=ONHAND(OCCURRENCE IN FEOSELECT) %DECREMENT=%ONHAND-1 CHANGE ONHAND(OCCURRENCE IN FEOSELECT)- TO %DECREMENT JUMP TO GETCASH END IF END FOR PRINT 'SELECTION DOES NOT EXIST TRY AGAIN' JUMP TO GETVAL END FOR * * IF CUSTOMER IS READY TO PROCEED WITH THE SALE, THEN * COMMIT THE TRANSACTION. IF NOT, THEN BACKOUT RECORD * UPDATED * GETCASH: %CASH=$READ('DID YOU GET CASH/CREDIT CARD FROM - CUSTOMER Y/N:') IF %CASH EQ 'Y' THEN COMMIT JUMP TO FINISH ELSE BACKOUT PRINT 'INVENTORY WAS NOT UPDATED ' PRINT 'PURCHASE STOPPED' JUMP TO DONE END IF FINISH: PRINT 'TRANSACTION COMPLETED' PRINT 'THANK YOU' DONE: *COMMENT END *

Design considerations for transaction backout files

This section identifies the factors to consider when designing an application that uses transaction backout files.

Transaction backout provides increased file logical consistency over the FIND share lock and FOR loop exclusive lock, and provides increased data sharing over the FIND AND RESERVE exclusive lock. However, effective use of the transaction backout facility depends on careful design and implementation.

Update requests

Requests that update transaction backout files cannot access non-transaction backout files in any way. This restriction ensures that all update units for a transaction backout file are logged correctly, can be backed out, and do not overlap with any update units that cannot be backed out.

Non-updating requests can access any type of file, and requests that update non-transaction backout files can read transaction backout files.

ON ATTENTION units

ON ATTENTION units should be used within requests to avoid inadvertently backing out an active update unit. If an ON ATTENTION unit is not specified and the user presses one of the ATTENTION identifier (AID) keys at the terminal or enters *CANCEL at a terminal I/O point, then the request is cancelled. The cancellation causes an automatic backout of the current update unit if the request updates transaction backout files.

CCATEMP space

The backout facility must have the necessary information to backout each active update unit in the Model 204 run. A log of compensating updates is built for each active unit on the system file, CCATEMP. When the unit ends or is backed out, the log for that particular unit is discarded.

To minimize the amount of CCATEMP space used, update units should be designed to contain only a few file updates. Units of a sizable amount can greatly increase the amount of CCATEMP space used by Model 204. Therefore, update units should be committed frequently to minimize the size of the backout log.

Logical inconsistency

Although transaction backout does increase the logical consistency of a file through the lock pending updates option, logical inconsistency can occur when an update unit is backed out. For example, logical inconsistency can arise when a unit involving DELETE RECORD is backed out because deleted records are not locked by the lock pending updates option.

Example

The following requests illustrate such a logical inconsistency:

User 1	User 2
BEGIN
SMH: FIND ALL RECORDS FOR WHICH
NAME = SMITH
END FIND
FOR EACH RECORD IN SMH
DELETE RECORD
END FOR
JNS: FIND ALL RECORD FOR WHICH	BEGIN
NAME = JONES	FD.RECS: FIND ALL RECORDS FOR WHICH
END FIND	NAME = SOLOBY OR -
FOR EACH RECORD IN JNS	NAME = SMITH OR -
ADD TYPE = SPECIAL	NAME = SAUNDERS
.	END FIND
.	FOR EACH RECORD IN FD.RECS
.	ADD TYPE = SPECIAL
.	END FOR
.	FD.SPEC: FIND ALL RECORDS FOR WHICH
.	TYPE = SPECIAL
.	END FIND
.	PRT: FOR EACH RECORD IN FD.SPEC
.	PRINT NAME AND TYPE
.	END FOR
DEL: BACKOUT	END
ALL: FIND ALL RECORDS
END FIND
FOR EACH RECORD IN ALL
PRINT NAME AND TYPE
END FOR
END

User 1 deletes the set of records with NAME = SMITH. Although the update unit is not complete, the deleted set of records is not locked. Before user 1's unit completes, user 2 finds the set of records with NAME = either SOLOBY, SMITH, or SAUNDERS. There is no locking conflict because the deleted records are not locked. User 2 adds a field to the found set, prints a report, and ends.

User 1 then decides to backout the unit in progress. The deletion of the SMITH records is in the backed out unit and the SMITH records reappear on the file. However, because the SMITH records do not have the TYPE = SPECIAL field added by user 2, there is a logical inconsistency. The chances of this type of inconsistency can be reduced by keeping units short, especially when the units involve record deletion. If user 1 had a COMMIT statement after the DELETE RECORD loop, no inconsistency would arise unless the backout was automatically activated during that short piece of the user request. It also is likely that the records deleted by an application are meant to be deleted, and a logical inconsistency in a set of records intended for deletion is unimportant.

FILE RECORDS statement

Similar logical inconsistency can occur using the FILE RECORDS statement because FILE RECORDS does not lock any records. For the FILE RECORDS statement, a FIND statement can be used to lock the records to be updated in share mode, or FIND AND RESERVE can be used to lock the records in exclusive mode. If the FIND set is locked exclusively and not released until after the update unit containing the FILE RECORDS statement has ended, then logical inconsistency is prevented.

Terminal I/O points

Terminal I/O points should not be placed between the start of an update unit and the unit's end or backout. This precaution stems from the exclusive lock placed on updated records. If a response is required from a terminal operator either to complete or backout an update unit, there is a possibility that a set of records could be locked for an extended period of time.