|
|
|
A feature introduced in V8.14 affected the behavior of NXTVREC in physical order when it encountered the "record space" for a new record that had not been committed and was written in a space that was not being reused. Instead of reporting a VFLG_ERR (error 158), that new feature skips the uncommitted "record space" (unless the reading is by the transactor, which would see the uncommitted record).
Details
The change affects how variable-length records are internally marked during transaction processing of pre-image space. The behavior prior to V8.14 marked the record header in a way that was considered invalid, causing a VFLG_ERR (158) error. The newer behavior sees the record as a deleted record (actually a pending insert) and skips to the next record as in a "read committed" transaction isolation.
This change is limited to the internal handling of header marks for newly added variable-length records.
Indexed files are not affected by these changes because pending key inserts are handled differently under transaction control.
These changes do not include changes to the physical files, record structures on disk, or other transaction control.
Reverting Back to the Old Behavior
These changes can be reverted back to the original (prior to V8.14) behavior using the keyword:
Changes in the Latest Revision
The changes introduced in the V11 release address the issues with the earlier change as follows:
If the reader has requested acquiring locks on the records that it reads, the physical read acquires a lock on that record and respects the lock before proceeding (earlier the lock was not respected) producing one of the following outcomes:
If... |
Then... |
Locking the record fails with error 42 (DLOK_ERR) because another connection has the record locked and the reader requested non-blocking locking. |
The physical record read function returns error 42. |
The record is committed (already, or when the lock is released). |
The record read proceeds as usual, and the record that would have been skipped is returned to the caller. |
The record is deleted or is a “resource.” |
The physical record read function continues scanning the data file, reading the next record. |
The record header contains an invalid record mark. |
The physical record read function returns error 158 (VFLG_ERR). |
Further changes have been introduced to reduce the occurrence of the 158 (VFLG_ERR) without skipping any record by changing the record header marker management during record addition.
COMPATIBILITY NO_VFLG_ERR can be used to disable this new handling and restore the earlier (post V8.14) behavior for the rare circumstance in which the old behavior is desired.
