Thank you very much Ann.
There is a statement in Turkish:
"It is not enough, if it is not more than enough!"

Regards,

Ali

--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:

> Allen wrote:
> >
> > Can anyone please tell me when the firebird will keep the record
> > version?
>
> Firebird uses record versions in three ways:
>
> 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