Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38705 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 378 invoked from network); 2 Jul 2008 17:45:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Jul 2008 17:45:02 -0000 Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 88.198.8.16 bigtime.backendmedia.com Linux 2.6 Received: from [88.198.8.16] ([88.198.8.16:45793] helo=bigtime.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 36/69-37564-C9EBB684 for ; Wed, 02 Jul 2008 13:45:01 -0400 Received: from localhost (unknown [127.0.0.1]) by bigtime.backendmedia.com (Postfix) with ESMTP id 0F7854144009; Wed, 2 Jul 2008 17:48:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at backendmedia.com Received: from bigtime.backendmedia.com ([127.0.0.1]) by localhost (bigtime.backendmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhcCDlqrsFRO; Wed, 2 Jul 2008 19:48:10 +0200 (CEST) Received: from [192.168.0.151] (77-57-23-243.dclient.hispeed.ch [77.57.23.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mls@pooteeweet.org) by bigtime.backendmedia.com (Postfix) with ESMTP id 7E3AA4144006; Wed, 2 Jul 2008 19:48:10 +0200 (CEST) Cc: Message-ID: To: "Bijl, Gomar" In-Reply-To: <6873E3E399117E4BA9FD3854A3DB93814B67EC@NL67S011.cal-consult.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 2 Jul 2008 19:43:42 +0200 References: <6873E3E399117E4BA9FD3854A3DB93814B67EC@NL67S011.cal-consult.nl> X-Mailer: Apple Mail (2.926) Subject: Re: [PHP-DEV] [PATCH] ODBC_Pconnect should not Commit/Rollback database transactions of previous data From: mls@pooteeweet.org (Lukas Kahwe Smith) On 26.06.2008, at 10:46, Bijl, Gomar wrote: > Hi > > We have a problem with the (ODBC) persistent database connection. We > have found that every PHP-session, using the same dsn, user and > password, are getting the same persistent connection by a reasonable > chance. > Also meaning that if a database transaction was not finished, other > PHP-session can do a rollback or commit of that transaction. Right, I presume you are aware of the documentation on this topic, which affects all rdbms extensions. Just to be sure here is the link: http://php.net/manual/en/features.persistent-connections.php > To overcome these problems one has to tag the connections. I suggest > to > use a new parameter on ODBC_(p)connect: Tag, a string parameter. If > used > it tries to re-connect to the connection with the same tag, if not > existing it creates a new-connection. > For example the tag parameter is filled with the session_ID() to > ensure > that a connection is bounded to one PHP-session. But also an extension > on this value is possible: (Session_ID() + 'Log') or (Session_ID() + > 'Data'). > And if somebody does not uses this tag parameter, it works in the old > way, so these solution is downwards compatible. Several extensions offer a "new_link" optional boolean parameter to ensure that a new connection is returned if there is already an existing connection in this request: http://php.net/mysql_connect IIRC this "feature" (returning an existing connection link of a section connection is made to the same server in the same request) is not present in all extensions, but since ext/mysql was sort of a template for many extensions, I think a lot of developers copied this behavior. Note that this parameter is not available in the pconnect alternatives. ideally the odbc extension should do a "change user", which would clean up all the session specific stuff inside the connection (next to open transactions, there are other stuff like date formats etc that could also be set). i am not however sure if this feature exists in all rdbms. afaik the mysql developers are looking to implement this into mysqlnd. either way, any solution should try to be consistent across all affected extensions. regards, Lukas Kahwe Smith mls@pooteeweet.org