Succinctly, I think rollback on termination is the only option that makes any sense - but the DBMS must implement that. There are circumstances (kill -9 on Unix) where there is nothing the Perl ensemble can do about the behaviour of the incomplete TX. And,
although the driver can (and in my view should) rollback anything that has not formally been committed, there is still a chance that the DBMS will not do as you would expect.
That is true, of course.
But the situation is no better when users have to explicitly commit() or rollback() before disconnect(). A kill -9 would cause as much trouble then as when the DBD module would call rollback() on their behalf.
Perhaps, as far as rigorous behaviour goes, the DBI documentation could just be updated to say, if my suggestion is followed, that a rollback will always happen assuming that the relevant processes are not killed. If they are killed, then the default database behaviour takes over. If all of the processes are allowed to keep running, then a rollback is guaranteed.
And DESTROY() already does what I suggest for disconnect(), which is the best it can to be rigorous under the circumstances.
-- Darren Duncan
