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?

Reply via email to