| Subject | Re: [firebird-php] Proper transaction & deadlock handling |
|---|---|
| Author | Lester Caine |
| Post date | 2016-11-21T09:05:18Z |
On 21/11/16 03:11, Daniel Miller dmiller@... [firebird-php] wrote:
written in 'c++' ... The original problem was down to very occasional
drop-outs on the then phone connections so the code was modified to
verify the connection was still live and re-wake it if not. Even today I
still get a few resets a year ... and a few stuck processes on Firebird
which since the clients also insist on windows are fixed with a monthly
reboot of the systems. That is with W10 at least XP only needed a reboot
occasionally ... so much for 'progress' :( Your trigger will be
different, but the basic agro is the same and one just needs to ensure
the changes get logged, even if it means retrying the next 'poll'.
should be no reason for a conflict. UNLESS you are trying to update the
same record .. such as some count totalling both streams. Don't include
that SQL in the stream code, only store and commit the records. I get
away without the summary data and just generate it with counts of
records which can be slow, but business logic which generates summaries
for a single stream are a tidier approach and more scalable if that sort
of data needs to be created. Firebird is very good at business logic ...
one of the reasons I originally switched over in the 90's ... but the
flow still needs to be cognisant of the bottleneck points ... nothing to
do with the language being used to generate them ;)
--
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
> The trouble is these messages are coming from some long running "daemon"I have a very similar problem on a system that polls remote displays ...
> type processes that I leave running. PHP may not be the preferred choice
> for such but I'd rather reduce the number of languages I need to juggle per
> project.
written in 'c++' ... The original problem was down to very occasional
drop-outs on the then phone connections so the code was modified to
verify the connection was still live and re-wake it if not. Even today I
still get a few resets a year ... and a few stuck processes on Firebird
which since the clients also insist on windows are fixed with a monthly
reboot of the systems. That is with W10 at least XP only needed a reboot
occasionally ... so much for 'progress' :( Your trigger will be
different, but the basic agro is the same and one just needs to ensure
the changes get logged, even if it means retrying the next 'poll'.
> These processes (there are two copies of the same script running) pollOK - if you are writing new records from different streams then there
> remote devices (1 each) and update the database with new events as needed.
> These are where the deadlocks occur.
should be no reason for a conflict. UNLESS you are trying to update the
same record .. such as some count totalling both streams. Don't include
that SQL in the stream code, only store and commit the records. I get
away without the summary data and just generate it with counts of
records which can be slow, but business logic which generates summaries
for a single stream are a tidier approach and more scalable if that sort
of data needs to be created. Firebird is very good at business logic ...
one of the reasons I originally switched over in the 90's ... but the
flow still needs to be cognisant of the bottleneck points ... nothing to
do with the language being used to generate them ;)
--
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