Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104886 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 1504 invoked from network); 23 Mar 2019 14:46:03 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.204) by pb1.pair.com with SMTP; 23 Mar 2019 14:46:03 -0000 Received: (qmail 10255 invoked by uid 89); 23 Mar 2019 11:38:40 -0000 Received: by simscan 1.3.1 ppid: 10249, pid: 10252, t: 0.0410s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 23 Mar 2019 11:38:40 -0000 To: internals@lists.php.net References: <95e918c8-aaeb-d700-cc08-30f10a07162d@lsces.co.uk> Message-ID: <01765a23-de18-47c3-732d-bced9094b0c5@lsces.co.uk> Date: Sat, 23 Mar 2019 11:38:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Unbundle ext/interbase From: lester@lsces.co.uk (Lester Caine) On 22/03/2019 16:25, Nikita Popov wrote: > I've created a patch forhttps://bugs.php.net/bug.php?id=72175 (last > comment), which seems to be the biggest open problem in the interbase > extension. I'd appreciate it if you or someone else who uses firebird could > test this. OK now got a test framework on the development machine where I can check things out. As expected, starting two connections to two different databases just works and simply copying $link to $link1 works as one would expect. But trying to create a second connection to the same database is currently giving me a crash and 'undefined symbol: GC_ADDREF' So I need to tidy up the patch to work with 7.2.16 :( The other part of the jigsaw is working out the significance of the 'default_link' in the code. And I'm taking this back to the firebird developers to check something out. As far as I am aware the firebird CLIENT will reuse an active connection to the database, but if one creates several connections in PHP and a couple end up linking to the same database where does a default one come into the picture. I think the code is basing decisions on the first connection made? Rather than the poll of active connections ... As stated in the bug report, there is no need to reconnect to the same database, but there will be a default transaction for the connection which requires explicit transactions to be handled and this may be why there is thought to be a need to open new connections when one simply manages extra transactions on the same link. Working of a singleton link just works and so in that case the bug is irrelevant rather than a show stopper. -- 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