--- In firebird-support@yahoogroups.com, Michael Ludwig <milu71@...> wrote:

>
> hvlad schrieb am 15.05.2010 um 07:08:38 (-0000):
>
> > > > > > Sweep interval is not a "number of transactions since the
> > > > > > last sweep".
>
> According to the book (p.518), it is the maximum size of the gap between
> the OIT and the OAT before automatic sweep will kick in.

Real formula is OST - OIT, not OAT - OIT

> > > > OIT can move forward without a sweep. There is two possible
> > > > reasons for OIT to stuck :
> > > > a) rollback via TIP
> > > > b) limbo transaction
>
> According to the book, again (p.515), a limbo transaction is the result
> of a failed two-phase commit involving multiple databases. So that's too
> advanced for me right now. :)
>
> What does "rollback via TIP" (Transaction Inventory Page) mean? Just a
> ROLLBACK, like, via ISQL?

Rollback is SQL statement. "rollback via TIP" is one of two possible ways (explained below) how this statement could run internally.

> > When Firebird performs ROLLBACK it have to choose between two ways :
> > a) mark transaction as dead in TIP, or
> > b) undo all changes by transaction and mark transaction as committed
> > in TIP.
> >
> > What to choose is dependent on size of internal undo-log of this
> > tansaction and urgency of rollback (when engine is shutted down,
> > active transactions should be rolled back as fast as possible).
> >
> > Case (a) means stuck OIT and additional job for cleaning dead
> > versions for next transactions.
> >
> > Case (b) means slower rollback but without any impact on next
> > transactions.
>
> > > So what I understood is that garbage collection is a reqular
> > > background activity that removes disposable versions of records,
> > > also termed "back versions". Nobody needs those any more, nobody
> > > (i.e. no transaction) is interested in them.
> >
> > Almost correct. Note, garbage collection (gc) could run not only in
> > background but also as part of regular read activity. This is
> > coperative gc.
>
> Seems that cooperative GC is what happens on CS (book, p.517), whereas
> SS works by tagging obsolete versions and relying on the background
> thread to clean them up. But maybe both tactics have been combined to
> work on both architectures since the book was published.

CS (and SC) still have only cooperative GC. SS since v2.0 have configurable GC policy : pure cooperative (as CS), pure background (as SS before FB2) and combined.

> > > Sweeping, on the other hand, occurs as a protecting measure to
> > > prevent the database from drowning in garbage, which is the result
> > > of old transactions (that were neither committed nor aborted) still
> > > lurking around and clinging on to those old versions of records.
> >
> > Sweep is total garbage collection. I.e. it cleans whole database.
> > While background and cooperative gc cleans only parts of database. As
> > sweep cleans backversions from all relations it have ability to move
> > forward stuck OIT - this is the most important difference from regular
> > gc.
>
> And it has this ability because it finds back versions belonging to a
> rolled-back or limbo transaction that are disposable but have not been
> removed because no other transaction has encountered those corners of
> the database during its activity?

Yes. Only note - versions, created by in-limbo transactions could not be removed until such transaction state will not be changed into committed or rolled back (dead). So, limbo transaction will hold OIT until administrator resolved it.

> And those back versions are only left over because when the transaction
> was rolled back, its changes weren't cleaned up immediately and it was
> not marked as committed in the TIP, so case (b) in your explanation?

Yes, if i understand you correctly :)

> But marked as dead instead, and the work left to be done later, so case (a)?

Yes.

> > Note, if application have good transaction control and there is no
> > very long running transactions, then regular gc (background and\or
> > cooperative) usually cleans almost all unneeded recors versions and
> > sweep have almost nothing to do, except of reading whole database (or
> > not whole - in FB3) and moving OIT forward.
>
> Which it can do because after having done the sweep the engine knows
> that there are no versions belonging to that transaction hanging around
> any more?

Exactly.

Regards,
Vlad