Subject | Re: [firebird-php] Re: Proper transaction & deadlock handling |
---|---|
Author | Lester Caine |
Post date | 2016-11-23T11:21:40Z |
On 23/11/16 10:25, masotti masotti@... [firebird-php] wrote:
on why the commit could not be completed? That same information should
be available in PHP? I am sure there is room for improvement in PHP on
the generic driver, but PDO has to work with the 'lowest common
denominator' that works for all database engines.
control where one has multiple clients taking stock for orders and each
has a transaction wrapping the whole order. The 'deadlock' is when two
clients are trying to grab the same stock so first one wins and takes
the stock while the second one then has to decide to drop an item, or
the whole order. Some of my suppliers using crap database engines just
take the order anyway and email you later that there was a problem ;)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>> > I've not tested this, but at a guess if a 1000 records were to beThat was my thought here ... although flamerobin will give information
>> > updated and the r eturn value was 999 this might inficate that one
>> > record had a deadlock and couldn't be updated, but 999 could. So
>> > perhaps you could commit the 999 and retry the 1 failure, which might be
>> > more efficient than rolling back all 1000 updates and retrying the whole
>> > lot. (As I say, just a guess following the same "logic".).
> Perhaps it's not possibile to commit the transaction in this case: the
> deadlocked record would refuse and commit return FALSE. Transaction
> atomicity must be respected.
on why the commit could not be completed? That same information should
be available in PHP? I am sure there is room for improvement in PHP on
the generic driver, but PDO has to work with the 'lowest common
denominator' that works for all database engines.
> AFAIK rollback is the only chance, and happens automagically at end ofOr you call a rollback and try again. My 'example' is always stock
> script execution.
control where one has multiple clients taking stock for orders and each
has a transaction wrapping the whole order. The 'deadlock' is when two
clients are trying to grab the same stock so first one wins and takes
the stock while the second one then has to decide to drop an item, or
the whole order. Some of my suppliers using crap database engines just
take the order anyway and email you later that there was a problem ;)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk