Hi all,

i've read many comments on this argument, but seems that ideas to solve this 
problem (if it is a true real problem in near future) are not many.

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.

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

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

Perhaps discussion about this should be better in fb-architect, but searching 
"transaction id" I found other type of philosophical discussion there. And in 
tracker.. nothing at all? A note should be somewhere, but cannot find it right 
now.

Comments?

Ciao.
Mimmo.



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

Reply via email to