TMF Application Programmer's Guide (G06.24+)

TMF Programming Environment
HP NonStop TMF Application Programmer’s Guide—522419-004
1-18
Enscribe Capabilities
therefore, applications using Enscribe files can encounter what is called “the deleted
record problem.”
Consider the case in which one transaction (designated T2) is using a loop to read a
sequence of employee records arranged in alphabetic order and another transaction
(designated T2) has previously deleted one of the records.
When T2 starts its read loop, the state of the employee file is as follows:
Record #1: ANN
Record #2: BEN
[ Record #3: CHARLIE ] (deleted by T1)
Record #4: DYLAN
Record #5: EDDIE
Record #6: FRANCO
EOF
As T2 loops through the file, it accesses the following sequence of records:
ANN
BEN
DYLAN
EDDIE
FRANCO
If transaction T1 aborts while T2 is reading the record DYLAN, for example, the delete
operation is backed out and the file now is as follows:
Record #1: ANN
Record #2: BEN
Record #3: CHARLIE
Record #4: DYLAN
Record #5: EDDIE
Record #6: FRANCO
EOF
If T2 were then to reexecute its read loop, it would not get the same results it did the
first time.
Summary of Levels of Consistency in Enscribe Files
When you are using TMF to protect Enscribe files, you are always guaranteed at least
level-1 consistency.
You can approximate level-2 consistency by:
•
Not using any of the SETMODE 4 read-through options (all read operations must
wait for existing locks to be released)
•
Using the READLOCK and READUPDATELOCK procedures instead of READ and
READUPDATE, explicitly releasing the record lock (UNLOCKREC) after each read
is complete
You can achieve level-3 consistency by locking the entire file at the start of your
transaction and then letting the disk process unlock it implicitly as part of the