| Subject: | rollback() at db::DESTROY = cargo cult? |
I see a highly suspicious comment around line 343 of Driver.xst:
Show quoted text
> The application has not explicitly disconnected. That's bad.
> To ensure integrity we *must* issue a rollback. [...] if we don't
> rollback, the server may automatically commit! Bham!
> Corrupt database!
Are there actually eyewitnesses of any database doing this? It would
definitely be a critical bug on its behalf. E.g. PostgreSQL will never
do this; it waits for the client app to issue an *explicit* commit
statement, as it should. If the Pg socket goes down the tubes halfway
through a transaction, the server will simply rollback it (it's easy to
verify with psql: start a transaction, insert some tuples, then killall
-9 psql; restart psql, the tuples are gone).
Please remove this preventive rollback, or at least move it into the
DBD's of the buggy databases if any. For a properly ACID-compliant DBMS,
the rollback-on-DESTROY behavior is useless, if not harmful (if the
rollback itself fails, e.g. because the database itself went down before
DESTROY, entire provinces of heck may break loose).
Pursuant to the Perl way of things, it seems desirable that one be able
to safely forget about a DBI handle that is no longer needed, as is
already the case with all other kinds of Perl objects, XS or not (e.g.
filehandles, sockets, GTK widgets...)