On Mon Sep 04 18:36:33 2006, jre@scanlaser.nl wrote:
Show quoted text> DBD::ExampleP::db doesn't define commit or rollback and I found that if I
> add
>
> sub connect { return 1; }
> sub rollback { return 1; }
>
> (around line 420 of ExampleP.pm), then the "Can't locate" messages go away,
Which is very odd because DBD::ExampleP::db is a subclass of the DBD::_::db class in which
the DBI implements default commit and rollback [kind of - long story].
Show quoted text> but the "Already in a transaction" error on the second call to
> begin_work stays. Not sure if this is the correct fix though since if I
> change the method definitions to include shift->STORE( AutoCommit => 1 );
> then all the new tests pass ok (except for the ones that test {BegunWork},
> so maybe I should have included a STORE for that too? I don't know enough
> about who should be doing what here.).
>
> So is the fix just to reset AutoCommit and BegunWork in the driver?
I think the key is to find out why the 'Can't locate method' is happening on the server side.
The DBI dispatcher has special code for handing commit/rollback/BegunWork which isnt
getting invoked if the methods can't be found.
Show quoted text> If so, I'm a bit surprised, since I'm sure that the first time I came
> across the problem I was using the *same* driver (I think it was ODBC):
> (a) directly, where commit "did the right thing" and (b) via proxy, where
> it didn't. I'll see if I can reproduce that (may be a couple of days
> though).
That's worth doing since some of the behaviour we're seeing is probably just a side effect of
ExampleP not properly (appearing to) support transactions.
Tim.