Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74514 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86060 invoked from network); 27 May 2014 05:44:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 May 2014 05:44:14 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:57651] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 72/E2-00171-C2624835 for ; Tue, 27 May 2014 01:44:13 -0400 Received: (qmail 1470 invoked by uid 89); 27 May 2014 05:44:09 -0000 Received: by simscan 1.3.1 ppid: 1462, pid: 1467, t: 0.0760s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 27 May 2014 05:44:09 -0000 Message-ID: <53842720.1020800@lsces.co.uk> Date: Tue, 27 May 2014 06:48:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <5383B035.4060806@sugarcrm.com> In-Reply-To: <5383B035.4060806@sugarcrm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Persistent PDO supports From: lester@lsces.co.uk (Lester Caine) On 26/05/14 22:20, Stas Malyshev wrote: >> I am just not sure, is the previous behavior is on purpose? or >> >any other reasons? > No, I don't think it's on purpose, it looks like a bug. PDO has a few simple assumptions, such as only allowing one connection per transaction, which is fine for most engines, but Firebird/Interbase has a very useful cross database transaction mechanism which PDO can not support. Persistent connections are another are where it's how the engine implements this which is the 'problem' as much as what PDO does. What 'persist' says is basically say 'use an existing connection' so how does sqlite actually support connection pooling? A quick scan of the sqlite manual would suggest that it requires fully thread safe operation to do that, and that you need a later version of sqlite. So is this an engine specific problem or a problem with the way PDO tries to simplify the connection model? -- 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