>
>
> 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).
I think it's better for the DBI to define what happens, rather than letting
the DBMS specify. In the case of ADO or ODBC, you really don't know what
the underlying DBMS will do, as these both can connect to Sybase, Informix,
Oracle, etc.
I would rather see the DBI define it and make driver authors commit or
rollback during disconnect than attempt to determine what the DBMS does...
It should be possible to have a "commit_on_disconnect" flag that defines
commit, rollback or neither. Neither would be the default to avoid breaking
code. The application could then set $dbh->{DISCONNECT_TRANS} =
DISCONNECT_COMMIT (or DISCONNECT_ROLLBACK or DISCONNECT_DBMS)... In fact,
the DBI could do this without bothering the driver authors by doing it
inherently. The only potential issue I see is the non-explicit disconnect
or during global destruction.
Regards,
Jeff
