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

[Pavel C. <pc...@us...>]

Ann,

On 15 Dec 2002 at 13:10, Ann W. Harrison wrote:

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

Yep, I had a temporary mind darkening :-) Transaction numbers that are 
not in transaction state table are committed ones.

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

But when client dies and server notice, server performs the rollback, 
don't he ? If undo log is used on rollback to rewind changes and allow to 
mark transaction as committed instead, client or network failure should 
not affect OIT in most cases (every time undo log is used).
 
> 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.

But when sweep is performed on backup ? I would suppose that restore is 
not necessary then.

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

So you say that GC can expunge rolled back versions beyond OAT, leaving 
there just those that are not removable (i.e. limbo) ? 
 
> > > 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.

But I meant read-only (by definition in trn parameter block) read 
committed transactions you mentioned earlier. They internally acquire pre-
committed status, don't they ?

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

I see. That would really make a difference. But does this really need a 
bookkeeping ? How about an extension logic in VIO_chase_record_version 
that will notice subsequent versions from committed transactions and mark 
it for GC (and extended GC to handle that, of course) ?

Best regards
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information