Excellent Ann, you had explained it very clearly (as usual).
Greetings.
Walter.
On Mon, Jan 16, 2012 at 12:51 PM, Ann Harrison <aharri...@nuodb.com> wrote:
> On Mon, Jan 16, 2012 at 8:24 AM, u.maso...@libero.it
> <u.maso...@libero.it> wrote:
> >
> > I remember that in 8086 era, when addressable memory became cheaper and
> bigger
> > than dimension reserved in opcode space (24 bits IIRC), hardware
> architecture
> > changed a bit, implementing relocation tables, where low level bits
> where the
> > displacement in a page and higher bits instead where used as a pointer
> in a
> > page table containing the base address of the real memory page.
>
>
> A relocation table for transactions is an interesting idea. Let me
> explain how transaction
> identifiers are used. It's very simple, and, given that transaction
> numbers generally go up
> over time, some major simplification is possible.
>
> Record versions are identified by transaction number of the
> transaction that created them.
>
> Transactions that don't insert, update, or delete records are of no
> interest to anyone once
> they end. The long term value in transaction identifiers is only to
> identify record versions.
>
> Transactions have four states: committed, rolled back, limbo, and
> active. The first two
> are pretty obvious.
>
> Limbo is the state that a two-phase commit enters when it has
> agreed that it can rollback or commit as necessary, with no
> possibility of error in either
> path. Normally, transactions are in limbo very briefly until their
> partner transactions all
> agree on a direction and commit or rollback. The problem that
> two-phase commit solves
> is a system crash during a commit on several sites. If that happens
> some of the sites
> may have committed and the other sites must commit the transactions in
> limbo when
> they recover.
>
> Active is more interesting than it looks. When allocating a new
> transaction inventory
> page, Firebird sets every transaction to active. When Firebird
> restarts after a crash or
> shutdown it searches the transaction inventory pages for transactions
> between the
> oldest active and the next transaction. If it finds any transactions
> in the active state,
> it changes them to rolled back.
>
> This leads to a couple of simplifying assumptions.
>
> When a transaction starts, it can be certain that all transactions with
> higher
> transaction numbers are active.
>
> Transactions keep track of the state of older transactions down to the
> "oldest interesting"
> which is the first transaction left in the database that did not
> commit. Sweeping the database
> moves the "oldest interesting" by removing changes made by
> transactions that rolled back.
>
> Older record versions have lower transaction numbers than newer
> versions. Figuring out
> what record version to use is pretty easy. Find the first version
> that was committed when
> the reading transaction started.
>
> >
> > As a parallel in our case, not many transaction IDs are important,
> interesting
> > or whatever you want call them, between 0 and next transaction number, a
> lot of
> > them could be ... "forgotten".
>
> OK. So how would you do a remap?
>
> Reusing the identifiers of transactions that created record versions
> that are still in the
> database is a bad idea. Resetting all the transaction identifiers of
> mature records (records
> without back versions) is possible but would require a mega-sweep
> (vacuum?) that would
> be slow, and, unfortunately, cannot reset the most recent transaction
> identifiers.
>
>
> However, the final state of transactions that don't make changes is
> kept on transaction inventory
> pages. Those numbers could be reused if those transactions could be
> identified and if the code
> could be changed so a new transaction 128 understood that transactions
> 129 - 4,000,000,000
> are committed and that changes by transaction 100 are newer than
> changes by transaction
> 3,999,999,970, but that changes by transaction 3 are older.
>
> >
> > I know that transaction management is not implemented in hardware, but
> having
> > this in memory could help and shouldn't be very big in size.
>
> I think a relocation table between unused transaction numbers in the
> 32-bit range
> to virtual transaction numbers in the 64 bit range could be pretty
> big. And it would
> have to be permanent, durable, on disk, and current.
>
> > AFAIU many classes uses transaction information and probably transaction
> ID
> > relocation algebra should be overloaded in the transaction class (don't
> know if
> > are there any such class, it's completely a hypothetical reasoning).
>
> The relative age of record versions is critically important to any
> MVCC system. The
> "relocation algebra" has to be permanent.
>
> > With a management like this, are any chance to re-compact them? If a
> page of
> > "relocatable IDs" has no more "pending" transaction, should be discarded
> and
> > the next can downgrade to occupy the freed "address space": this maybe
> needs a
> > use count, with the good and the bad it has.
>
> Err, those transaction identifiers are written into record versions on
> disk. They
> can't be released without rewriting the pages.
>
> > Anyway, as are they are implemented now, it's not a simple task,
> because, and
> > maybe here i'm very wrong, they are used for different purposes: mark
> different
> > versions of a record as they are created AND time ordering any
> correlated on
> > unrelated change in DDL or DML of the database (AND maybe other things I
> don't
> > remember now or I'm not aware).
>
> No, there's no correlation between transaction id's and DDL operations.
> Changes
> to table definitions are managed with record format versions.
>
> Having thought about it for a minute, relocation of transaction
> identifiers sounds hard,
> error prone, and likely to lead to slower and slower operations as the
> number of available
> identifiers shrinks.
>
> Cheers,
>
> Ann
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
