hvlad schrieb am 16.05.2010 um 22:51:01 (-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

Okay, then it should probably be corrected on p.838 as well. So the OST,
the Oldest Snapshot Transaction - what is it, and how does it differ
from the OAT?

I found the following brief document quite helpful:

http://esdc.ru/ - MultiGenerational Architecthure in short

To quote from the passage about cooperative garbage collection:

\,,,/
(o o)
------oOOo-(_)-oOOo------
At the first (or zero, as you wish) database page server
stores not only next transaction number, but also all
transaction numbers needed to support TIP.

They are:

* Oldest Active Transaction (OAT) - the lowest
transaction number that is still in Active state.
* Oldest Interesting Transaction (OIT) - the lowest
transaction number that have non-committed state. It
can be OAT or number of oldest transaction in Rollback
or In Limbo state.
* Oldest Snapshot Transaction (OST) - it's
slightly complex than just snapshot number:
o "read only read committed" transactions don't
have such number
o "read write read committed" have OST equal to
their number
o snapshot have OST equal to OAT

If transaction discovers version that is committed, and have
transaction number < OST, engine can delete that version.
-------------------------

So it sounds like there is one OST per transaction, and than probably
another one per server, which is probably the oldest among all the
per-transaction OSTs? Not sure at all.

Another document I found [1] seems to corroborate that view. All in
all, there does not appear to be too much literature available on the
subject!

[1] [PPT] 1117 Understanding InterBase Transactions, by Bill Todd
http://conferences.embarcadero.com/article/32280

> 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.

> > 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 :)

Sorry, I meant case (a) in your explanation, not (b), as I erroneously
wrote! The back versions have not been cleaned up as would have been the
outcome of (b), but rather they're still hanging around as the engine
had opted for (a), probably because there was too much work or too
little time for (b).

Thanks for all your answers, this has been very helpful!
--
Michael Ludwig