| Subject | Re: [firebird-support] Multi-Version Consistent Read Question |
|---|---|
| Author | Ann Harrison |
| Post date | 2011-12-13T18:18:07Z |
On Tue, Dec 13, 2011 at 9:39 AM, Joey S. <prog.stuff.123@...> wrote:
(and InterBase and PostgreSQL) guarantees that old versions of records
will be available as long as there are transactions that can read
them. All these systems store old records in the actual data files
and use a garbage collector (or vacuum) to remove them when the last
transaction that can possibly read them exits. The method used by
Oracle (and MySQL's InnoDB) keeps old versions in log files which are
purged periodically. A long running transaction can get inconsistent
data if the log file that contained the record version appropriate for
it has been purged.
So, the experience is that using the Firebird/Postgres method, readers
always get a consistent view of data. With Oracle and InnoDb, less
so.
Firebird keeps information about each running transaction, including
the oldest transaction that was running when the transaction started.
When choosing record versions to remove, Firebird compares the
transaction identifier in the record version header with the "oldest
of the oldest" - i.e. the oldest transaction that was running when the
oldest transaction now running started - and keeps one version older
than that.
If the oldest transaction running is 200 and the oldest transaction
running when it started was 175 and the chain of record versions goes
199, 176, 175, 174, 173, 140, 123, Firebird can remove the versions
created by 173, 140, and 123. The newer versions will all stay until
transaction 200 exits and the next "oldest of the oldest" is higher
than 175.
Does that help?
Best regards,
Ann
>MVCC can be implemented in several ways. The method used by Firebird
> I am researching methods to achieve high throughput for a learning chat
> application I am designing as a self-led student. I came across the
> Multiversion Control method of ACID and have a theoretical question: though
> it seems remote that a reader of data wouldn't get an "old" read what has
> been the experience and when this occurs what methods are available to
> alert the read user that data has been updated?
(and InterBase and PostgreSQL) guarantees that old versions of records
will be available as long as there are transactions that can read
them. All these systems store old records in the actual data files
and use a garbage collector (or vacuum) to remove them when the last
transaction that can possibly read them exits. The method used by
Oracle (and MySQL's InnoDB) keeps old versions in log files which are
purged periodically. A long running transaction can get inconsistent
data if the log file that contained the record version appropriate for
it has been purged.
So, the experience is that using the Firebird/Postgres method, readers
always get a consistent view of data. With Oracle and InnoDb, less
so.
Firebird keeps information about each running transaction, including
the oldest transaction that was running when the transaction started.
When choosing record versions to remove, Firebird compares the
transaction identifier in the record version header with the "oldest
of the oldest" - i.e. the oldest transaction that was running when the
oldest transaction now running started - and keeps one version older
than that.
If the oldest transaction running is 200 and the oldest transaction
running when it started was 175 and the chain of record versions goes
199, 176, 175, 174, 173, 140, 123, Firebird can remove the versions
created by 173, 140, and 123. The newer versions will all stay until
transaction 200 exits and the next "oldest of the oldest" is higher
than 175.
Does that help?
Best regards,
Ann