Subject | Multiple connections |
---|---|
Author | Lester Caine |
Post date | 2019-03-23T12:06:32Z |
I could do with a bit of input for an area that is causing problems in
PHP and is part of the reason they want to drop support for the firebird
extension.
I the vast majority of my dealings with PHP we open a single connection
to a single database do all the work perhaps with a few transactions
wrapping functions, and then close down the connection. All very simple
and working perfectly in the distributed builds of PHP.
In some cases one may want to open a connection to a second database,
with or without cross transaction support. One simply pushes or pulls
data on a second link while keeping the main link live.
The problem introduced around PHP7.0.3 has resulted in an attempt to
open the same database a second time resulting in neither connections
working, and with a recent patch from one of the PHP developers, trying
to open the second connection is crashing out so we know we are in the
right area ;) use a different database and all is fine.
The documented way this is supposed to work is that PHP simply reuses
the already established connection so the extension side of things just
needs to know that there is an existing connection to that database and
simply copy it's link. In user land PHP we simply use the same resource
... so while the bug is irritating it's not a show stopper and one
simply changes mindset on using links to Firebird
The main question is about just where persistent connections are managed
in this setup. Since invariably I'm returning to the same set of
databases when ever there is a new page request I've got PHP persistent
connections switched on, but what part does the firebird client play in
this, in particular where several instances of PHP may be running all
for the same website so using the same database. Things just work and
I'm happy with performance but perhaps now is the time to take more
interest especially if I'm going to need to dig into the code myself :(
I've not even looked to see if FB3 would benefit from a different
approach between client and PHP ... what I have just works ...
--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
PHP and is part of the reason they want to drop support for the firebird
extension.
I the vast majority of my dealings with PHP we open a single connection
to a single database do all the work perhaps with a few transactions
wrapping functions, and then close down the connection. All very simple
and working perfectly in the distributed builds of PHP.
In some cases one may want to open a connection to a second database,
with or without cross transaction support. One simply pushes or pulls
data on a second link while keeping the main link live.
The problem introduced around PHP7.0.3 has resulted in an attempt to
open the same database a second time resulting in neither connections
working, and with a recent patch from one of the PHP developers, trying
to open the second connection is crashing out so we know we are in the
right area ;) use a different database and all is fine.
The documented way this is supposed to work is that PHP simply reuses
the already established connection so the extension side of things just
needs to know that there is an existing connection to that database and
simply copy it's link. In user land PHP we simply use the same resource
... so while the bug is irritating it's not a show stopper and one
simply changes mindset on using links to Firebird
The main question is about just where persistent connections are managed
in this setup. Since invariably I'm returning to the same set of
databases when ever there is a new page request I've got PHP persistent
connections switched on, but what part does the firebird client play in
this, in particular where several instances of PHP may be running all
for the same website so using the same database. Things just work and
I'm happy with performance but perhaps now is the time to take more
interest especially if I'm going to need to dig into the code myself :(
I've not even looked to see if FB3 would benefit from a different
approach between client and PHP ... what I have just works ...
--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk