> Had you forgotten that triggers can call stored procedures?
> Can you imagine the mess a database could get into if commits
> could occur right in the middle of other DML?

And the mess increases when you take into account transactions
that span several databases. Two phase commit is coordinated
by client, but Bupp wants commit to be initiated by server.
The server does not talk to other servers participating in 2pc.

Or take this example of "usefullness" of selfcommitting:
- start transaction against two databases
- withdraw money from account in one database
update accounts set money=money-1000000 where id=123;
- store that money into account in second database
update accounts set money=money+1000000 where id=456;
- now you (or computer) realize that something is wrong
(e.g. incorrect target account) and issue rollback.
- you just lost 1000000 because the first update (its triggers) did a favor to you
and automagically committed the first update, so the money are missing
on both accounts.

There should be only one authority that controls transactions -
either client (as in current Firebird), or the server (after implementing
some new feature, like stored scripts).
The idea that transaction is controlled from two places at the same time
is crazy like car driven by two steering-wheels.

Ivan