"Doug Chamberlin" <DChamberlin@...> wrote in message
news:5.1.0.14.2.20020129062931.01a86600@......

>
> So you are saying that what is being reported here is the transaction
> number of the most recent transaction which used snapshot transaction
> isolation level? Or is it the oldest transaction of that type which is
> still uncommitted? Looks to me that it is the oldest uncommitted.

The engine plays loose with that number. You can read the details in tra.c,
tpc.c and vio.c, for example.
For one side, garbage collection cannot proceed past the oldest snapshot,
but the transaction may have marked dead, etc. When a new calculation is
being done to determine the oldest active, if the oldest snapshot is older
than the computed oldest active, it's simply updated to the same number than
the oldest active.
Ah, but if the engine discovers through the locks that there's an "alive"
txn that's older than the supposed oldest active, that number is updated to
reflect the state reported by the lock manager (provided that the VMS define
is not in effect, of course, did you want easy behavior? <g>). This is
probably because the engine used the VMS' lock manager but it has to use its
own lock manager in all other platforms.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing