Jonathan Vanasco wrote:
1 - Someone who understands this better than I - note this in the
Apache::DBI documentation. Probably in this paragraph:
I'll add this to my list of Apache-DBI things to look at ... but that
won't be for about 10 days.... or so....
=current_pod
Transactions: a standard DBI script will automatically perform a
rollback whenever the script exits. In the case of persistent
database connections, the database handle will not be destroyed and
hence no automatic rollback occurs. At a first glance it seems even
to be possible, to handle a transaction over multiple requests. But
this should be avoided, because different requests are handled by
different servers and a server does not know the state of a specific
transaction which has been started by another server. In general it
is good practice to perform an explicit commit or rollback at the end
of every script. In order to avoid inconsistencies in the database in
case AutoCommit is off and the script finishes without an explicit
rollback, the Apache::DBI module uses a PerlCleanupHandler to issue a
rollback at the end of every request. Note, that this CleanupHandler
will only be used, if the initial data_source sets AutoCommit = 0. It
will not be used, if AutoCommit will be turned off, after the connect
has been done.
=cut
2 - would it be possible to catch the die on a RaiseError, and
have a setting to issue an explicit rollback if wanted? i'm not too
familiar with dbi - but i'd love something like that
Have you looked at HandleError/RaiseError combo?
