This message follows after my last "commoditization suggestion #1" email.
For a context, I reference this portion of the DBI user documentation, under disconnect():
The transaction behaviour of the disconnect method is, sadly, undefined. Some database systems (such as Oracle and Ingres) will automatically commit any outstanding changes, but others (such as Informix) will rollback any outstanding changes.
I propose that, unless there already is one which I missed, an information method is added to $dbh database handles (or otherwise a static driver-specific information function), which returns a definitive answer to the question of what this particular database system will do with incomplete transactions, that is outside of the control of the DBD module itself (each DBD module overrides it).
Here's a possible description of such a method, which returns true if rollback is what happens, and false if either commit is what happens, or transactions aren't supported at all. This is written as if the rollback was a "feature" that is desired in a database, and the function says whether that feature is supported or not.
TRAN_ROLLBACK_ON_DEATH
The actual data storage product in use by this DBD will roll back any incomplete transactions during the recovery process following either the death (from any means such as power failure or hardware fault or killed or crashed process) of the data storage product itself or a prematurely severed connection from the DBD (such as a killed or crashed Perl program, or network failure). This feature is intrinsic to the data storage product itself, and the DBD can't do anything about it. This feature is separate from or additional to a DBD behaviour feature that guarantees the DBD will issue a roll back on disconnect/DESTROY when there is no process death or network failure. If the data storage product's current or only possible behaviour is to commit incomplete transactions following a severed connection or during crash recovery, then TRAN_ROLLBACK_ON_DEATH is explicitly *not* supported.
The idea here is that someone's Perl program can discover programmatically which available databases support a desired behaviour.
(FYI, this description is based on a Rosetta feature description that I just added. If DBI and the DBD modules support this discovery process natively, then I can use that value rather than implementing my own lookup table for it.)
Of course, modify my suggestion to best fit the community's needs. The exact form that the information can be delivered in doesn't matter to me as long as I can get it (unambiguously).
-- Darren Duncan
