Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60693 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74797 invoked from network); 30 May 2012 21:43:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 May 2012 21:43:43 -0000 Authentication-Results: pb1.pair.com header.from=glopes@nebm.ist.utl.pt; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=glopes@nebm.ist.utl.pt; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error) X-PHP-List-Original-Sender: glopes@nebm.ist.utl.pt X-Host-Fingerprint: 193.136.128.22 smtp2.ist.utl.pt Linux 2.6 Received: from [193.136.128.22] ([193.136.128.22:56846] helo=smtp2.ist.utl.pt) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/A1-60719-B8496CF4 for ; Wed, 30 May 2012 17:43:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 421D6700045F; Wed, 30 May 2012 22:43:36 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 5W7N8n1+reLC; Wed, 30 May 2012 22:43:35 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id E3B897000447; Wed, 30 May 2012 22:43:35 +0100 (WEST) Received: from damnation.mshome.net (damnation-air.nl.lo.geleia.net [IPv6:2001:470:94a2:4:7d06:1af1:ea64:2d52]) (Authenticated sender: ist155741) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 46AB32007075; Wed, 30 May 2012 22:43:33 +0100 (WEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "internals@lists.php.net" , "Christian Ferrari" References: <1338323273.24780.YahooMailNeo@web29506.mail.ird.yahoo.com> <1338408656.56325.YahooMailNeo@web29506.mail.ird.yahoo.com> Date: Wed, 30 May 2012 23:43:32 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?= =?utf-8?Q?ca_do_I=2ES=2ET=2E?= Message-ID: In-Reply-To: <1338408656.56325.YahooMailNeo@web29506.mail.ird.yahoo.com> User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [PHP-DEV] PHP and two phase commit transactions From: glopes@nebm.ist.utl.pt ("Gustavo Lopes") On Wed, 30 May 2012 22:10:56 +0200, Christian Ferrari wrote: > You correctly understood the only necessary changes are related to > open/close connection to the resource manager (database); this is a > consequence of XA and TX specifications. > I've not completely understood your statement "add some hooks to the > several database extensions" and I would need some more details; is this > mailing list the right place to discuss about this type of details or is > there a better place? What I meant was that you should not couple the database extensions to your C library. Instead of having: struct conection *conn; #ifdef LIXA if (lixa_is_active()) { conn = lixa_whatever(); } else { #endif conn = do_default(); } prefer something like: extern struct connection (*get_connection_override)(void); ... if (get_connection_override) { conn = get_connection_override(); } else { conn = do_default(); } You can do this in different ways -- by having a PHP wide variable and generic function to retrieve and close connections that would be passed the type of resources an other parameters; you could have a different scheme for eachDB extension, etc. -- those details are relatively unimportant. > 1. Is there any interest in "two phase commit" inside PHP community? > Without a real interest, every effort would be useless. It is very difficult to determine the future demand for something that does not exist yet. Microsoft introduced filesystem transactions in Windows Vista, and it's considering deprecating them. But given the prevalence of JTA in the Java world and the developments in PHP in the last years I would not be surprised if there was significant demand for this. And given the current tendency to use more specialized databases (see JCR client implementations), it may become more important in the future. > 2. Is there anyone available to help me in implementing the interface > between LIXA and database extensions in "the right way"? After some > analysis I discovered some database extensions are really sophisticated > and injecting a bug is simpler than adding a well implemented feature. I > wouldn't break some working code. > I can review your patches and help you along the way. Note that stable branches generally do not receive new features, so you should develop against the development branch (master). If it's your thing, you can fork PHP on github: https://github.com/php/php-src -- Gustavo Lopes