Record Versions - Firebird

When an update request is successfully posted to the server, Firebird creates and writes to disk a reference linking the original row image as seen by the transaction —sometimes called a delta—and a new version of the row, incorporating the requested changes. The original and new row images are referred to as record versions. When a new record version is created by a newer transaction than the one that created the “live” version, other transactions will not be able to update or delete the original unless the owner transaction of the new version rolls back. The versioning process is described in detail in the previous chapter.

Until the transaction is eventually committed, it does not touch the “live” version again until the commit occurs. Within its own context, it treats the posted version as if it were the latest committed version. Meanwhile, other transactions continue to “see” the latest committed version. In the case of “snapshot” transactions that started before our transaction, the latest committed version that they see may be older than the one seen by our transaction and by other transactions that either started later or are in READ COMMITTED isolation.

Dependent Rows

If the table that has an update posted to it has foreign keys linked to it, the server creates deltas of the rows from those tables that “belong to” the updated row. Those dependent rows, and any that are dependent on them through foreign keys, are thus made inaccessible for update by other transactions too, for the duration of the transaction.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics