> My understanding was that transactions from lost connections would be
> rolledback rather than committed. From my experimentation that does
> seem to be the case. Under what circumstances does Firebird commit a
> transaction that was left by a lost connection?

Firebird never on its own accord 'commit' an open transaction running
under a connection that has disappeared ungracefully (eg trip over
power cord). They are rolled back, but it may take several hours for
your OS to bother to tell Firebird if a socket is broken.

Some connection components have a default action that occurs after a
timeout, or something similar. These sorts of features may see the
commit being issued when your application is shutdown. I would advise
against using autocommit style programming, even if your component
suite supports it. It is really important in Firebird that you
understand when your transactions are started and when they end. This
should be reasonably trivial for the OP, considering they have already
said there application is stateless.

At the simplest level, it may look something like this

Tra.StartTransaction;
try
// Do queries
Tra.Commit;
except
Tra.Rollback;
raise;
end;

(although you should only catch the relevant exceptions, not be lazy
like me here).

http://en.wikipedia.org/wiki/Atomicity

"An atomic transaction is a series of database operations which either
all occur, or all do not occur ("fail", although failure is not
considered catastrophic). A guarantee of atomicity prevents updates to
the database occurring only partially, which can cause greater
problems than rejecting the whole series outright."

In other words, until you issue a commit, your records "don't exist".

> Does that happen if
> the transaction was only used to read data, or do some writes get
> committed too?

IIRC, Rollbacks on read only transactions are converted to commits
because it is cheaper and otherwise makes no difference.

Adam