FAQ Frequently Asked Questions

Christian Ferrari

Abstract

Why should I use LIXA?

LIXA supplies an XA compliant Transaction Manager:

  • if you needed two phase commit protocol, there's a chance LIXA could be useful to you
  • if you didn't need two phase commit protocol, LIXA wouldn't help your software development

What's two phase commit protocol?

Wikipedia supplies a generic answer.
Here's a basic example: Why two phase commit.

Standards

Which standards are implemented by LIXA?

LIXA adheres to two X/Open standards:

Development

Which development languages can be used to develop an application that uses the LIXA Transaction Manager?

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.

Are there available examples?

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

How can I use LIXA and PHP together?

To use LIXA and PHP together you have to patch the PHP engine distribution because:

  • the code of LIXA must be added
  • the code of the Resource Managers (database drivers) must be changed to integrate with LIXA Transaction Manager
    Please refer to LIXA Extensions reference guide for more details.

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.

Could LIXA become a standard PHP extension?

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:

  • LIXA library should switch from GPL license to a linkable friendly license; this should be a requirement only in the case PHP distributed LIXA itself. The use case "the user download PHP and download LIXA separately" does not create the concern about linking non GPL code with GPL code, because the final user is linking them by itself, it's not distributing a derivative work. LIXA library with LGPL might be a future option if many users asked it
  • the integration between LIXA and PHP core should be engineered in a different way using some decoupling code technique
  • LIXA extension would be a Linux/UNIX-like only extension and this hurts some PHP Windows users
  • many PHP applications use MySQL with MyISAM back-end and could not get the benefits of LIXA without switching to InnoDB back-end
  • it's uncertain if such an extension will be used by any user.

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.

Can I use LIXA and PHP in a Microsoft Windows environment?

No, there's not a LIXA client for Windows O.S. available; LIXA and PHP are available only for Linux O.S.

Is there a coding style?

Yes, this page describes the [coding style] that should be followed for LIXA.

Operating Systems

Which operating systems can be used to execute LIXA project software?

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

Could LIXA be ported to UNIX operating systems?

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.

Could LIXA be ported to Microsoft Windows operating system?

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:

  • client (lixab and lixac libraries, utilities)
  • server (lixad state server).

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:

  • lixad state server uses "poll" function aggressively to manage the communication between client and server (TCP/IP) and to manage the communication between the threads (internal UNIX pipes)
  • lixad state server uses "mmap" function to implement transactionality.

"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.

Resource Managers

Which Resource Managers can be used with LIXA Transaction Manager?

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:

  • DB2 Express-C: version 9.7 (Ubuntu 8.04, 32 bit) was successfully tested
  • MySQL: version 5.0 (Ubuntu 8.04) and 5.1 (Ubuntu 10.04) was successfully tested; LIXA project supplies a stub library to expose an XA compatible interface because MySQL does not have it
  • Oracle XE/SE: version 10.2 (Ubuntu 8.04, 10.04), 11.2 (Ubuntu 10.04), 12.1 (CentOS 7, RHEL 7) was successfully tested
  • PostgreSQL: versions 8.3, 8.4 and 9.2 were successfully tested; LIXA project supplies a stub library to expose an XA compatible interface because PostgreSQL does not have it
  • WebSphere MQ: version 7.1 (CentOS 6.2, 32 bit) was successfully tested
    If you were interested in different Resource Managers, please join the community and describe your needs.

MySQL special notes

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.

License

Which type of license applies to LIXA project?

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

Why LIXA client library is released under the terms of GPL instead of LGPL?

Free Software Foundation does have an answer to this question.

GPL imposes too much restrictions... bla bla bla...

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.


Related

Wiki: Home
Wiki: Why two phase commit
Wiki: coding style

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks