[Dbix-class] Recovering from a failed transaction ?

Matt S Trout dbix-class at trout.me.uk
Wed Aug 8 13:16:19 GMT 2007


On Wed, Aug 08, 2007 at 12:10:56PM +0100, Richard Robinson wrote:
> 
> [ Matt points out offlist that I messed up with the headers & sent this as
>   a reply in a different thread. Sorry, reposted]
> 
> 
> I'm still getting to grips with all this, I think I must be missing
> something obvious.
> 
> I'm playing around with transactions, to get a feel for how they go. So I
> have a little block of deletes and updates, called with
> 
> eval { $schema->txn_do($coderef); };
> 
> all very much as per the DBIx::Class::Storage doc. Run it with DBIC_TRACE
> and I can see it go "BEGIN WORK ...<statements> ... COMMIT" (this is mySql),
> or write a deliberate error and I see "ROLLBACK", just as I was hoping, all
> very nice; until I go back to the calling page (it's a Catalyst app) and try
> it again, when it doesn't seem to do the transaction thing any more - the
> statements are issued bare, without the surrounding BEGIN WORK / ROLLBACK.
> And they run up to the failing one, and duly leave things in a mess - once a
> transaction's failed, they seem to be left disabled . Is this the expected
> behaviour, is there something obvious that my deal_with_failed_transaction()
> should be doing to bring them back to life ?  Or is this an artefact of
> (a different) stupidity in my code ?

Did you set AutoCommit to 0 in your Cat config? If so, remove that, DBIC
will default it to 1 which is usually what you want for txn_do

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/                    http://www.shadowcat.co.uk/ 



More information about the DBIx-Class mailing list