Hi guys!

I agree with Colin that this concept of a tx log is a separate thing
than a mirror machine.

Anyway, IIRC GemStone writes on the tx log (it typically does that until
it reaches a certain size, and then it rotates over say 10 different
files in a cycle. If the tail - the tx log file to be overwritten - is
not yet applied onto the db file, then you will get an exception) and
the actual application of the data into the db file is done by a
separate process. Again IIRC.

So when you commit the call to commit returns when the data has been
flushed into the tx log - because then it has been secured to secondary
storage and can not "disappear". There is no point in waiting
additonally for the data to be applied to the db file, so that can be
done asynchronously. And thus the process applying the transactions can
"lag" and in theory you could end up in the situation described above -
that the next tx log to be written hasn't yet been applied to the db
file.

Anyway, just some info. :)

regards, Göran