Re: [PHP-DEV] PHP and two phase commit transactions

2012-05-30 Thread Christian Ferrari
 

 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



Re: [PHP-DEV] PHP and two phase commit transactions

2012-05-30 Thread Sanford Whiteman
 1. Is there any interest in two phase commit inside PHP
 community? Without a real interest, every effort would be useless.

I can't speak to a critical mass of interest, but as PHP and MySQL
are closely coupled in the real world, until relatively recently (when
Inno became the default) that meant that PHP and MyISAM were best
buds. I don't know how you could do 2PC between two
transaction-unaware back ends. I could see one transaction-aware and
one transaction-unaware working by running synchronously w/the
transactional one first (?).

So my sense is that PHP, because of MyISAM's ubiquity, isn't the ideal
language target for 2PC (compared to Java/.NET where the most
enterprise back end is assumed, however inaccurately!). 

That doesn't mean there wouldn't be some interest, though.

-- S.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] PHP and two phase commit transactions

2012-05-30 Thread Gustavo Lopes
On Wed, 30 May 2012 22:10:56 +0200, Christian Ferrari cam...@yahoo.com  
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] PHP and two phase commit transactions

2012-05-30 Thread Johannes Schlüter
On Tue, 2012-05-29 at 21:27 +0100, Christian Ferrari wrote:
 Dear all,
 I'm the author of LIXA project (http://lixa.sourceforge.net/) and I
 would discuss a little about two phase commit transactions for PHP
 applications.

Besides all technical discussions etc one legal comment, on the project
page I read:

Which type of license applies to LIXA project?

The whole LIXA project is released under the terms of GNU Public
License (GPL) version 2. 

http://sourceforge.net/apps/mediawiki/lixa/index.php?title=FAQ:_Frequently_Asked_Questions#License

It then mentions bla bla bla about restrictions imposed by the GPL.
One restriction is that the GPL is not compatible with the current PHP
License. Therefore lixa can't be combined with PHP. See
http://www.gnu.org/licenses/license-list.html#PHP-3.01

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php