LIXA supplies an XA compliant Transaction Manager:
LIXA adheres to two X/Open standards:
C and C++ languages can be used to develop an application that uses the LIXA Transaction Manager.
TX standard describes two equivalent API: C and COBOL.
Since release 1.1.1 LIXA supports both C/C++ and GNU COBOL.
LIXA 0.9.0 integrates LIXA and PHP Zend engine: it provides a patch that must be applied to PHP source distribution. The integration between LIXA and PHP must be considered experimental.
LIXA provides basic examples for many different configurations.
C language examples are available in directory doc/examples.
COBOL language examples are available in directory doc/examples/cobol.
All the examples are fully documented in the LIXA reference guide manual
To use LIXA and PHP together you have to patch the PHP engine distribution because:
The state of PHP integration must be considered experimental.
At the time of this writing only MySQL and PostgreSQL can be used with LIXA and PHP.
The integration of LIXA and PHP is really difficult to address, if you could help, your contribution would be extremely appreciated.
I started a thread on php-internals mailing list discussing about "if" and "how" LIXA could become a standard PHP extension.
Some interesting points of view emerged:
Are you really interested in LIXA and PHP? Do you really think two phase commit is interesting for PHP application? Join lixa-generic mailing list and post your point of view: I will be happy to discuss about it.
No, there's not a LIXA client for Windows O.S. available; LIXA and PHP are available only for Linux O.S.
Yes, this page describes the [coding style] that should be followed for LIXA.
LIXA project is a GNU/Linux based software; there is no a concept of "Certified Platform" because LIXA is an open source project.
The updated list for tested platforms is available in file TestLog
The porting of LIXA to UNIX operating systems (IBM AIX, Hewlett Packard HP-UX, Oracle Sun Solaris, ...) should not be too difficult because all the LIXA source code sticks to POSIX standard. As a suggestion, the GNU toolchain should be used (gcc, gmake, automake, autoconf, libtool) to reduce the effort; using a different (proprietary) toolchain could amplify the necessary effort.
Please join lixa-general mailing list to share your porting experience and ask for support.
As a general rule, LIXA code is designed to leverage the power of the POSIX API of a UNIX-like platform; as a consequence a porting to Microsoft Windows implies the design of some components to leverage the Windows API.
The porting could be splitted in two main tasks:
Porting the client source code should be easier than porting server source code because it uses many functions provided by GLIB and GLIB is available for Microsoft Windows too. This statement does not mean it's only the matter of recompiling it: some POSIX functions are used by client source code too, but changing it to use GLIB and/or other multi platform libraries should not be very difficult.
Porting the server source code to Microsoft Windows is a completely different task and some kernel stuff should be re-designed from scratch:
"poll" and "mmap" are the foundation of lixad performance and scalability: using alternative functions for Microsoft Windows must be designed by a Windows expert.
A partial approach could be porting the client code to Microsoft Windows and leaving the server code on Linux: it should work fine because the client/server protocol is quite platform and language independent (it's XML with an ASCII control field), but it would leave you with two different platforms: Microsoft Windows and Linux. It might be good for you, it might be bad for you.
Please join lixa-general mailing list if you are interested in porting LIXA to Microsoft Windows operating system.
Any XA compliant Resource Manager should be easy to use in conjunction with LIXA Transaction Manager. The LIXA project itself tested some open source and proprietary Resource Managers:
Only tables managed by the InnoDB back-end are eligible for transactionality and LIXA Transaction Manager can not override this behaviour because it's a consequence of MySQL internal design.
MySQL is affected by a serious bug related to XA: Bug #12161 "Xa recovery and client disconnection". The bug breaks XA specification because MySQL rollbacks the transaction when a client disconnects even if the "XA prepare" was successfully passed.
MySQL 5.7.7 solved the bug. If you use MySQL 5.7.7 or upper, you should use LIXA 0.9.4 that fixes the correlated LIXA bug.
The whole LIXA project is released under the terms of GNU Public License (GPL) version 2.
Free Software Foundation does have an answer to this question.
There is a lot of confusion about what you can do and what you can't do when using a GPL licensed library.
This page can give you a lot of interesting information about it.
I do think you do not have any real restriction until you are not trying to distribute a GPL-ed software.