Woody, > Maybe I'm a little dense, (probably :), but doesn't FB already know what the > oldest interesting transaction id is? Why couldn't transaction numbers be > allowed to wrap back around up to that point? As long as transactions are > committed at some point, the oldest transaction would move and it would > solve most problems being run into now.
The oldest interesting transaction is the oldest on that is not known to be committed. If the oldest interesting transaction is 34667, and you're transaction 55778, you know that anything created by transaction 123 is certain to be committed. Now lets assume that you're transaction 4294967000 and the oldest interesting transaction was 4294000000 when you started. (Probably ought to mention that (IIRC) a transaction picks up the value of its the oldest interesting on startup). Then the transaction counter rolls around and some new transaction 3 starts creating new versions... You know they're committed, so you read the new data. More generally, how do you know the difference between the old transaction 3 record versions which you do need to read and new new transaction 3 records that you don't want to read? > I will accept any and all ridicule if this seems idiotic ... Not at all idiotic. This stuff is complicated. Cheers, Ann ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
