Subject | Re: [firebird-support] Question about Record Versioning??? |
---|---|
Author | Ann W. Harrison |
Post date | 2005-04-20T17:22:43Z |
Allen wrote:
1) to provide a stable snapshot of data.
2) to identify update conflicts between concurrent transactions
3) to replace the undo log for recovery after transaction failure.
Although 1 and 2 are not of interest in a single user application, 3 is
always required in a transaction-based system. So, the quick answer, is
that any modification or deletion creates a record version, regardless
of transaction modes or number of concurrent users.
Record versions are removed after the end of the last transaction that
can read them. The actual mechanism depends on the architecture and
version of Firebird. In V1.x, classic uses cooperative garbage
collection and superserver uses a garbage collect thread. In Firebird2,
classic is still cooperative and superserver uses a combination of
cooperative and a garbage collect thread. In Vulcan, all modes use
cooperative garbage collection.
Cooperative garbage collection means that when a transaction encounters
a record with unneeded old versions, it immediately removes them. That
is "unfair" in that a transaction that does a massive delete does the
delete and moves on, leaving at least two record versions - the last
data and a stub record to say it was deleted - and all index entries.
When the delete is "mature", meaning that no running transaction can see
the old record, the next transaction to stumble over the record must
remove the record versions and index entries. That can be quite expensive.
When the garbage collect thread is running, the transaction that
stumbles over a record version that can be removed just puts it on a
list. When the garbage collect thread starts, it reads its list and
removes all the unneeded record versions from all records on the page.
A problem occurs when the garbage collect thread doesn't get enough
cycles and garbage starts building up. Then the system gets very slow.
The garbage collection in V2 mixes cooperative and thread-based garbage
collection. If the record version can be removed conveniently - without
reading any new pages, then the transaction that finds it removes it.
Otherwise, it goes on a list for the garbage collect thread.
More than you wanted to know...
Regards,
Ann
>Firebird uses record versions in three ways:
> Can anyone please tell me when the firebird will keep the record
> version?
1) to provide a stable snapshot of data.
2) to identify update conflicts between concurrent transactions
3) to replace the undo log for recovery after transaction failure.
Although 1 and 2 are not of interest in a single user application, 3 is
always required in a transaction-based system. So, the quick answer, is
that any modification or deletion creates a record version, regardless
of transaction modes or number of concurrent users.
Record versions are removed after the end of the last transaction that
can read them. The actual mechanism depends on the architecture and
version of Firebird. In V1.x, classic uses cooperative garbage
collection and superserver uses a garbage collect thread. In Firebird2,
classic is still cooperative and superserver uses a combination of
cooperative and a garbage collect thread. In Vulcan, all modes use
cooperative garbage collection.
Cooperative garbage collection means that when a transaction encounters
a record with unneeded old versions, it immediately removes them. That
is "unfair" in that a transaction that does a massive delete does the
delete and moves on, leaving at least two record versions - the last
data and a stub record to say it was deleted - and all index entries.
When the delete is "mature", meaning that no running transaction can see
the old record, the next transaction to stumble over the record must
remove the record versions and index entries. That can be quite expensive.
When the garbage collect thread is running, the transaction that
stumbles over a record version that can be removed just puts it on a
list. When the garbage collect thread starts, it reads its list and
removes all the unneeded record versions from all records on the page.
A problem occurs when the garbage collect thread doesn't get enough
cycles and garbage starts building up. Then the system gets very slow.
The garbage collection in V2 mixes cooperative and thread-based garbage
collection. If the record version can be removed conveniently - without
reading any new pages, then the transaction that finds it removes it.
Otherwise, it goes on a list for the garbage collect thread.
More than you wanted to know...
Regards,
Ann