Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104913 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66413 invoked from network); 24 Mar 2019 11:12:09 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.204) by pb1.pair.com with SMTP; 24 Mar 2019 11:12:09 -0000 Received: (qmail 32748 invoked by uid 89); 24 Mar 2019 08:04:58 -0000 Received: by simscan 1.3.1 ppid: 32741, pid: 32745, t: 0.0420s 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; 24 Mar 2019 08:04:58 -0000 To: PHP internals References: <33dee569-a06f-c5ab-d358-f7b8df3f8a76@lsces.co.uk> <1166897a-379d-4e6f-d132-744171ea19d5@lsces.co.uk> Message-ID: <0f59d47c-f170-21c8-33b7-4a98120b64d5@lsces.co.uk> Date: Sun, 24 Mar 2019 08:04:58 +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 24/03/2019 01:42, Kalle Sommer Nielsen wrote: > Besides this, it has further magic behavior if the multiple > connections are created with the same credentials as one in the same > process, I'm not sure if this is fixed with Nikita's patch. But that IS the point here ... In fact many people using Firebird with PHP use it in 'embedded mode', where the client is actually the server process and explicitly blocks a second physical connection! The default $link is the initial default transaction and ibase_trans creates additional links encapsulating additional transactions on the database if work flow requires. The difficulty and one that PDO can never support is that a transaction CAN encapsulate two or more different physical connections and it is this which dictates that operations need an explicate '$link_or_trans_identifier'. Personally I use $conn and $transnnn explicitly to keep track of things ... but if you only open a single physical connection and don't add transactions then the 'default_link' is the only packet of workflow. ibase_connect specifically says "In case a second call is made to ibase_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned. The link to the server will be closed as soon as the execution of the script ends, unless it's closed earlier by explicitly calling ibase_close(). " It was this action that as broken around 7.0.3 ... and it's probably totally incompatible with 'thread safe'? But the firebird client can handle multiple calling processes - and persist connections - so the 'bug' is probably in how PHP and Firebird interact in a new world? We are still using a 20+ year old model. For a simple single transaction packet of work one opens a connection does the work and if the activity crashes it is rolled back otherwise it autocommits when finished. Yes this is magic behaviour but it's the same magic behaviour that it has always done even on C and Delphi platforms and for the vast majority of PHP processes it's all that is needed? It's just not politically correct today? -- 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