Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60691
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com from 77.238.189.193 cause and error)
DomainKey-Status: good
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=DOia1ZYH5vTeSGU4oDtxrAabu0+Di5K3IKVzHW3vlcyYZIC2s/tNlqLxsUSxyHbfd+C6o3aqZCXCWbPUP78EYJR9f6LND9S0w4azZUlbe1hlroy5rLo+jtCcgIL2lA4s1l8cQRGufDIw1cNQS7UTNtpVMNdowWri5eF9/fdkmis=;
References: <1338323273.24780.YahooMailNeo@web29506.mail.ird.yahoo.com> <op.we28irwgidpuyk@damnation.mshome.net>
Message-ID: <1338408656.56325.YahooMailNeo@web29506.mail.ird.yahoo.com>
Date: Wed, 30 May 2012 21:10:56 +0100 (BST)
Reply-To: Christian Ferrari <camauz@yahoo.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>,
  "internals@lists.php.net" <internals@lists.php.net>
In-Reply-To: <op.we28irwgidpuyk@damnation.mshome.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP and two phase commit transactions
From: camauz@yahoo.com (Christian Ferrari)

>> =0A=0A>> These are the issues I partially solved integrating LIXA with P=
HP.=0A>> =0A>> 1.=0A>>=A0 XA interface is a C level interface: the PHP data=
base drivers must be=0A>> changed at C source level to avoid many leaps bet=
ween C and PHP code.=0A>> The most important PHP database drivers are distr=
ibuted with PHP core=0A>> itself =3D> patching their source code is equival=
ent to patch PHP core.=0A>> 2. As a consequence of the first point, the LIX=
A PHP wrapper itself should=0A>>=A0 be distributed with PHP core to avoid d=
ependencies between some core=0A>> extensions and an external extension.=0A=
>> 3. The TX API does not deal=0A>> with the concept of "connection" becaus=
e it's implicit: every=0A>> process/thread has its own connection with ever=
y Resource Manager=0A>> (database). Better explained: tx_open(), tx_begin()=
, tx_commit(),=0A>> tx_rollback(), tx_close() (and so on...) do not specify=
 the handlers=0A>> necessary to distinguish connection objects.=0A>> 4. The=
 TX API design does not take into account the concept of "persistent connec=
tions" and "connection pooling".=0A>> =0A>> I afforded issues 1 and 2 creat=
ing a global experimental patch for PHP=0A>> core itself (you can find it i=
n "ext/php" directory of LIXA tarball or=0A>> directly at SVN repository. h=
ttp://lixa.svn.sourceforge.net/viewvc/lixa/ext/php/).=0A>> Issue number 3 w=
as bypassed and, for the sake of trivial "hello world=0A>> equivalent examp=
les", the integration seems to work properly.=0A>> Issue 4 is quite difficu=
lt to address: I ignored "persistent connection"=0A>> disabling LIXA featur=
e when the application asks a persistent=0A>> connection, but I was not abl=
e to deal with Oracle "connection pools" of oci8 driver.=0A>> =0A>=0A>I hav=
e some concerns about the approach you're taking. I don't think a compile t=
ime dependency to LIXA is acceptable.=0A>=0A>Can't you add some hooks to th=
e several database extensions? From a glance at your patch, it seems you on=
ly need to change the behavior when getting a new connection and closing on=
e. This shouldn't be much work. Once that were done, one would be able to p=
lug the LIXA extension (or any similar extension). I don't think this appro=
ach would get objections from the extension maintainers and it is more vers=
atile.=0A>=0A>--Gustavo Lopes=0A>=0A=0A=0ADear Gustavo,=0AI've appreciated =
you feedback and the approach I followed to produce some experimental code =
could be changed for sure.=0AYou correctly understood the only necessary ch=
anges are related to open/close connection to the resource manager (databas=
e); this is a consequence of XA and TX specifications.=0AI've not completel=
y understood your statement "add some hooks to the several database extensi=
ons" and I would need some more details; is this mailing list the right pla=
ce to discuss about this type of details or is there a better place?=0ABefo=
re starting to implement the interface in "the right way" I have to collect=
 some feedback about the following issues:=0A1. Is there any interest in "t=
wo phase commit" inside PHP community? Without a real interest, every effor=
t would be useless.=0A2. Is there anyone available to help me in implementi=
ng the interface between LIXA and database extensions in "the right way"? A=
fter some analysis I discovered some database extensions are really sophist=
icated and injecting a bug is simpler than adding a well implemented featur=
e. I wouldn't break some working code.=0A=0A=0AAny hint/suggestion would be=
 appreciated.=0ACh.F.=0A