Subject | Re: [firebird-php] Proper transaction & deadlock handling |
---|---|
Author | Lester Caine |
Post date | 2016-11-22T12:30:06Z |
On 21/11/16 16:38, Daniel Miller dmiller@... [firebird-php] wrote:
from Firebird but as already said, this is because it's not necessarily
the operation that you carried out that is going to fail. The failure
will happen asynchronously to the actions which is why for some actions
it is an outer 'catch' which is needed to handle the failure. PHP is not
good at exceptions at this level so I can quite easily create a 'white
page' crash when something goes wrong on the Firebird connection. Is it
a PHP bug - well yes, and one we have simply grown used to because async
errors are something PHP can't easily recover from and in the past might
not even produce an error log entry. Nowadays there is usually a error
log entry so one can work out just where the problem is quicker.
This is one reason I set up processes that try to avoid the deadlock
condition in the first place. So I ask again ... which part of your
database process is trying to write to the same record which is what
will cause the deadlock. YES PHP could handle the problem better, but it
is much better to fix the source of the deadlock rather than having to
handle the result.
--
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
> You're absolutely right - the commit was missing from the sample II do accept that there is a problem with the way php handles the returns
> uploaded - though it should be present in all my active code. Revised block:
from Firebird but as already said, this is because it's not necessarily
the operation that you carried out that is going to fail. The failure
will happen asynchronously to the actions which is why for some actions
it is an outer 'catch' which is needed to handle the failure. PHP is not
good at exceptions at this level so I can quite easily create a 'white
page' crash when something goes wrong on the Firebird connection. Is it
a PHP bug - well yes, and one we have simply grown used to because async
errors are something PHP can't easily recover from and in the past might
not even produce an error log entry. Nowadays there is usually a error
log entry so one can work out just where the problem is quicker.
This is one reason I set up processes that try to avoid the deadlock
condition in the first place. So I ask again ... which part of your
database process is trying to write to the same record which is what
will cause the deadlock. YES PHP could handle the problem better, but it
is much better to fix the source of the deadlock rather than having to
handle the result.
--
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