Martijn Tonies wrote:

>>
>>Right, but Firebird is clever enough to not hold undo-logs
>>for _all_ commands executed inside transaction.
>>After some point the undo-logs are discarded.
>
>
> Huh? How does a "rollback" work then?
>

Very nicely, thank you.

The undo logs allow a transaction that fails under control -
deliberately rolled back by the client, or from a client disconnect
recognized by the still-running server - to undo its own changes.
That's a relatively new feature.

Earlier, a rollback just changed the state of the transaction on the
transaction inventory page from active to rolled back. Changes made by
the transaction were left in place, as they are now in the case of a
server crash. When a transaction reads a record version, it validates
the state of the transaction that created it against its list of
interesting transactions. If the transaction that created the record
version rolled back, the new transaction removes the record version and
replaces it with the next older one.

The undo log avoids two problems. If a transaction can completely undo
its changes, then it can mark itself as committed rather than rolled
back, so it's no longer an "interesting" transaction, which saves work
throughout the system. In addition, putting the cost of undoing a
transaction's work on its successors is "unfair" and tends to screw up
[dumb] benchmarks.

The downside of an in-memory undo log is that over time, it will fill up
all of memory.


Regards,


Ann