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
To clarify, I think that there are 2 different types of functionality being discussed here.
One functionality type can be controlled by DBI and/or the DBD and/or the user; it says whether an explicit rollback or commit is issued automatically by the DBI/DBD on disconnect() or DESTROY(). I agree this should also be implemented.
The other functionality type, which my latest message was mainly about, concerns simply getting information on a database engine behaviour that none of us have any control over. It is what happens when, for example, Perl crashes or the network goes down, or the database crashes. Our automatic commit/rollback won't be seen then, so the question is what the database would do with a partially completed transaction in its hands and no guidance from us.
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.
This is why I suggest for the information/metadata function to be a method on $dbh database handles. By the time that handle exists, we already know what kind of database we are connected to. So even ADO or ODBC, which can connect to several possible database engines, will know exacty which one they did have for a particular current $dbh. (Unless the ADO/ODBC protocol hides that information on purpose.) So an application should be able to know that a database engine will do what it wants during any type of failure. The function could *also* be static if the DBD is more limited and only connects to one type of database, but that is optional since only some DBD can implement a static version.
-- Darren Duncan
