Re: Re[6]: [Firebird-devel] Max transaction duration

[Ann W. H. <aha...@ib...>]

>On 13 Dec 2002 at 19:01, Ann W. Harrison wrote:
>
> > The OIT, oldest interesting transaction, is the first transaction that did
> > not commit.

At 11:51 AM 12/15/2002 +0100, Pavel Cisar wrote:
>Hi,
>
>Developers are often confused why rolled back transactions are
>"interesting". Actually, they just fall in "not committed" category, but
>more important are active and limbo trn.

Rolled back transactions are just as interesting as limbo and
active transactions, well to me at least.

>While active transactions are
>covered by OAT, limbo trn are not -> hence OIT (limbo trn can become
>committed in future!!!).

Actually, what's interesting is that all three types of records
require special handling.  Records created by transactions that
rolled back should be removed or at a minimum, ignored in favor
of an earlier version, if any.  Records created by transactions
in limbo either cause an error or are ignored, depending on the
state of the ignore_limbo transaction parameter.  Records created
by active transactions are ignored.

>I don't completely understand why rolled back
>trn are maintained through OIT in trn state table.

Because that's the only way that a transaction knows that
a record version was created by a transaction that failed.

>FB could handle back-
>version made by transactions that are not in trn state table as rolled
>back and ignore/gc them, but FB handles all three in the same way.
>
>If I'm not mistaken, IB/FB has an optimisation that allows to advance OIT
>on rollback.

Not to advance it, but a rolled back transaction that made no changes
is registered as committed.

>  Transactions maintain in-memory undo log of all changes
>made, and this log is used to unwind all changes on rollback, so OIT can
>advance (transaction is marked as committed).

So if a transaction rolls back in a controlled manner and undoes
all its changes, it too is marked as committed.

>  Transaction is marked as
>rolled back and thus interesting only when server goes up after abnormal
>termination (all active trn are marked as rolled back).

Network errors that break connections, users typing control-alt-delete,
any number of things can cause a transaction to fail in a way that
leaves it unable to undo its changes.

>So, the rollback
>command or when client dies does not freeze OIT,

I believe that client death does establish an OIT.

>  only server abend does.
>Of course, one can disable trn undo log in trn parameters. I'm also not
>sure if CS and SS behave the same way (but should).
>
> > Record versions created by the OAT and subsequent transactions can not
> > be garbage collected because they might be needed to provide a
> > consistent view for an active transaction.
>
>True, but that same apply for OIT transactions, because if they are
>limbo, they could be committed manualy.
>
> > The OIT is reset in one of two ways:  a sweep or a backup and restore.
>
>True, "by the way" garbage collection can't reset OIT. To do that, all
>row versions made by transaction must be removed, and only sweep and gbak
>read whole database and thus GC all those versions.

Actually it requires both a backup and a restore.  Gbak doesn't do the
bookkeeping necessary to notice what transactions it has undone.  Only
sweep does that.


>The big trn state table (due to big difference between OIT and actual
>transaction) only slow down a bit trn start, not the normal work. And of
>course, memory consumption is higher. But the real pain of stalled OIT is
>blocked GC

No.  The OIT does not block garbage collection.  A limbo record can not
be garbage collected, of course, but neither can it be modified or deleted,
so it's not going to start a long chain of back versions.

> > Read-only read-committed transactions do not affect the
> > OAT - they can go on forever without affecting garbage collection.  In
> > this case, unlike the OIT, the transaction must be declared as read-only,
> > not just be de-facto read-only.
>
>I'd like to add that they are actually handled internaly as pre-
>committed. They should be a solution to OIT/ OAT problem caused by use of
>CommitRetaing in 7x24 apps.

No, they aren't because read-committed transactions that update records
need to register themselves as active to avoid dirty reads.


> > The performance impact of the OIT, especially in the SS is probably not
> > significant.  The impact of the OAT is quite significant, particularly
> > in applications that repeatedly update the same records.
>
>I think that impact of OIT is almost the same as OAT. Applications that
>update the same records are problem on its own, because they made
>exceptionally long back-version chains due to inefficient GC (we
>discussed that in ib-architect some time ago).

Right, but that effect - delayed garbage collection - is independent
of the OIT.  The OIT itself has no effect on garbage collection.


> > That effect could be reduced by some bookkeeping that told the server
> > which record versions were important so intermediate versions could be
> > removed.  At the moment, it seems to me that the cost of that
> > bookkeeping and the complexity of removing intermediate record versions
> > is not worth the cost and risk.
>
>What do you mean by intermediate versions ? Many versions of single row
>that are made by one transaction ? I think that the bookkeeping is
>already there as undo log.

The intermediate versions are not created by a single transaction, but
by a series of transactions.  Suppose you start a consistency mode
(snapshot) transaction.  It stays open.  The next 60 transactions all
modify a single record, serially.  Each starts, modifies the record and
commits before the next transaction starts.

At the end, you'll have 61 versions of that record.  Only the oldest
one and the newest are interesting.  The 59 intermediate versions
are just taking up space.


Regards,

Ann
www.ibphoenix.com
We have answers.