I ran into an interesting glitch (and that’s not for lack of a better term) in the ADODB library for PHP today.
ADODB is a DB abstraction layer, allowing me to change the underlying DB engine without caring (much) about the code I’ve written. Change the driver name, perhaps the connection string, and everything should ‘Just Work’. It also claims to have a smart transaction handler, so that you can write (cribbed from their docs):
$DB->StartTrans();
CallBlackBox();
$DB->Execute("update table1 set val=$val1 where id=$id");
$DB->Execute("update table2 set val=$val2 where id=$id");
$DB->CompleteTrans();
And it should ‘Just Work’, with CompleteTrans detecting any failures in the SQL execution, and calling a rollback as needed (or commit if clean). So I decided to use it, as it’d be easier than doing my own transaction handlers, right?
Wrong. For whatever reason, it insists on issuing a rollback regardless of the state of the SQL executed. So even with a flawless insert, it executed a rollback. I haven’t got the time to investigate right now, but I’m wondering if it’s because I do ‘Begin, try { execute } catch exception () { debuglog() }, Complete’. It’s possible that the try/catch block is upsetting the state monitor of the transaction monitor.
Oh well. Back to hand-rolled transaction monitoring.