On Tue, 29 May 2012 22:27:53 +0200, Christian Ferrari <cam...@yahoo.com>
wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
