> For "commit expected" strategy when DML occures all changes are written
> directly to the tables and indexes but not marked as commited: then commit
> processing has only to flag data as commited which is fast enough. Rollback
> is quite slow then but rollback is really quite rear, usually one designs
> transactions to commit.. Is this what Firebird does?

You should read information about the "generational storage" which is
used in Interbase/Firebird (and also in PosrgreSQL but that's
different code).

In Short: On DML statements Firebird does copy the rows changed, the
old rows are still available for concurrent transactions.

It is obviously better not to make changes than to rollback the
changes out of the database.

Once changes are done using Rollback or Commit is an consequence of
logic not an question of performance.

Elmar