Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60688
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com from 77.238.189.200 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:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=NREfwbwQj9ygQM4omZWJM5F4QKAxQriuoUwJus3r73jyXXWZpmBFT+JGEovznGHrUoyprZfowYgWWs3+ST4wQCFIMzSBEWqBIRFa4swqSxGXfYmfKAl8za6zoMtOX/xHrCAaTEpiaOUuzfvYXhTA8HFTpQEjDphkEx6sF8b2cJg=;
Message-ID: <1338323273.24780.YahooMailNeo@web29506.mail.ird.yahoo.com>
Date: Tue, 29 May 2012 21:27:53 +0100 (BST)
Reply-To: Christian Ferrari <camauz@yahoo.com>
To: "internals@lists.php.net" <internals@lists.php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: PHP and two phase commit transactions
From: camauz@yahoo.com (Christian Ferrari)

Dear all,=0AI'm the author of LIXA project (http://lixa.sourceforge.net/) a=
nd I would discuss a little about "two phase commit" transactions for PHP a=
pplications.=0A"Two=0A phase commit" means I can write a program that uses =
two (or more) =0AResource Managers (for example databases, like MySQL and P=
ostgreSQL) =0Awith ACID transactions that span all the databases. With two =
phase =0Acommit I can perform a *global* commit that commits the changes in=
side =0Atwo or more databases at the *same* *time*. This is quite different=
 than=0A performing two (or more) distinct commits: with distinct commits i=
t may=0A happen the first one completes and the second one catches an error=
.=0A=0ALIXA=0A project implements two X/Open standards: "XA specification" =
and "TX =0A(transaction demarcation) specification". XA describes an interf=
ace =0Abetween the Resource Managers (databases) and the Transaction Manage=
r =0A(for example LIXA); TX describes an interface between the Application =
=0AProgram (your own custom software) and the Transaction Manager (for =0Ae=
xample LIXA).=0A=0AThe "TX (transaction demarcation) specification" =0Ais a=
 C API very easy to understand and use when you are developing a C =0A(or C=
++) software.=0A=0AWhen I started developing LIXA, I figured out =0Ait woul=
d have been straightforward to wrap it for other languages like =0APHP, Per=
l, Python, Ruby and so on...=0A=0AUnfortunately I discovered =0Ait's not ea=
sy to extend the TX API to other languages: creating a =0Awrapper for TX AP=
I is trivial because it's just the matter of some SWIG (http://www.swig.org=
/) hacking.=0AIntegrating the TX wrapped interface with *the* *environment*=
 is a completely different task.=0A=0AThese are the issues I partially solv=
ed integrating LIXA with PHP.=0A=0A1.=0A XA interface is a C level interfac=
e: the PHP database drivers must be =0Achanged at C source level to avoid m=
any leaps between C and PHP code. =0AThe most important PHP database driver=
s are distributed with PHP core =0Aitself =3D> patching their source code i=
s equivalent to patch PHP core.=0A2.=0A As a consequence of the first point=
, the LIXA PHP wrapper itself should=0A be distributed with PHP core to avo=
id dependencies between some core =0Aextensions and an external extension.=
=0A3. The TX API does not deal =0Awith the concept of "connection" because =
it's implicit: every =0Aprocess/thread has its own connection with every Re=
source Manager =0A(database). Better explained: tx_open(), tx_begin(), tx_c=
ommit(), =0Atx_rollback(), tx_close() (and so on...) do not specify the han=
dlers =0Anecessary to distinguish connection objects.=0A4. The TX API desig=
n does not take into account the concept of "persistent connections" and "c=
onnection pooling".=0A=0AI=0A afforded issues 1 and 2 creating a global exp=
erimental patch for PHP =0Acore itself (you can find it in "ext/php" direct=
ory of LIXA tarball or =0Adirectly at SVN repository. http://lixa.svn.sourc=
eforge.net/viewvc/lixa/ext/php/).=0AIssue=0A number 3 was bypassed and, for=
 the sake of trivial "hello world =0Aequivalent examples", the integration =
seems to work properly.=0AIssue 4=0A is quite difficult to address: I ignor=
ed "persistent connection" =0Adisabling LIXA feature when the application a=
sks a persistent =0Aconnection, but I was not able to deal with Oracle "con=
nection pools" of oci8 =0Adriver.=0A=0AIt's time to made a balance of LIXA =
and PHP integration: I=0A "successfully" integrated mysqli (with MySQL supp=
lied library) and pgsql =0Adrivers. There are some examples and 7 case test=
s available. =0A=0AI was *not* able to figure out a smart patch for "oci8" =
driver and I stopped my effort.=0A=0ATo=0A conclude, I think 98% of the use=
 cases does *not* need two phase =0Acommit, but if you are developing the o=
ther 2% of the use cases - =0Awithout two phase commit - you probably could=
 create some clumsy =0A"solution" to avoid the "two phase commit issue".=0A=
=0AWhat do you =0Athink about PHP and two phase commit? Do you think the ga=
me isn't worth =0Athe candle? Do you think there's room for two phase commi=
t inside the=0A PHP userland?=0A=0AIn the next future I will concentrate my=
 LIXA efforts=0A in expanding the number of different Resource Managers for=
 C =0Aprogrammers because "patching" PHP for LIXA integration is a too hard=
 =0Atask for me myself. Is there someone interested in picking-up LIXA PHP =
=0Aexperimental extension and going further with the task? Is there someone=
=0A interested in "two phase commit" and "distributed transaction =0Aproces=
sing" in general?=0A=0AEvery comment/hint/suggestion would be appreciated.=
=0A=0ARegards=0ACh.F.=A0=0A=0A---------------------------------------------=
----------------------=0ADecent workarounds outperform poor solutions