>> >> These are the issues I partially solved integrating LIXA with PHP. >> >> 1. >> XA interface is a C level interface: the PHP database drivers must be >> changed at C source level to avoid many leaps between C and PHP code. >> The most important PHP database drivers are distributed with PHP core >> itself => patching their source code is equivalent to patch PHP core. >> 2. As a consequence of the first point, the LIXA PHP wrapper itself should >> be distributed with PHP core to avoid dependencies between some core >> extensions and an external extension. >> 3. The TX API does not deal >> with the concept of "connection" because it's implicit: every >> process/thread has its own connection with every Resource Manager >> (database). Better explained: tx_open(), tx_begin(), tx_commit(), >> tx_rollback(), tx_close() (and so on...) do not specify the handlers >> necessary to distinguish connection objects. >> 4. The TX API design does not take into account the concept of "persistent >> connections" and "connection pooling". >> >> I afforded issues 1 and 2 creating a global experimental patch for PHP >> core itself (you can find it in "ext/php" directory of LIXA tarball or >> directly at SVN repository. >> http://lixa.svn.sourceforge.net/viewvc/lixa/ext/php/). >> Issue number 3 was bypassed and, for the sake of trivial "hello world >> equivalent examples", the integration seems to work properly. >> Issue 4 is quite difficult to address: I ignored "persistent connection" >> disabling LIXA feature when the application asks a persistent >> connection, but I was not able to deal with Oracle "connection pools" of >> oci8 driver. >> > >I have some concerns about the approach you're taking. I don't think a compile >time dependency to LIXA is acceptable. > >Can't you add some hooks to the several database extensions? From a glance at >your patch, it seems you only need to change the behavior when getting a new >connection and closing one. This shouldn't be much work. Once that were done, >one would be able to plug the LIXA extension (or any similar extension). I >don't think this approach would get objections from the extension maintainers >and it is more versatile. > >--Gustavo Lopes >
Dear Gustavo, I've appreciated you feedback and the approach I followed to produce some experimental code could be changed for sure. 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? Before starting to implement the interface in "the right way" I have to collect some feedback about the following issues: 1. Is there any interest in "two phase commit" inside PHP community? Without a real interest, every effort would be useless. 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. Any hint/suggestion would be appreciated. Ch.F. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
