This chapter explains what XTA is and how it can be used to develop applications that require to perform two phase commit ACID transactions.
XTA is a modern Application Programming Interface that has been specifically designed to enable two phase commit ACID transactions for polyglot microservice oriented applications.
Some interfaces, like TX Transaction Demarcation Specification [40], are today relegated to legacy applications and legacy use cases.
Other interfaces, like JTA Java Transaction API [41], are specific to a single language and/or a single runtime environment (Java/JRE).
XTA aims to provide TXaaS (Transaction as a Service) backend services that can be used by cloud native applications that, for one reason or another, require two phase commit ACID transactions among distributed applications [42].
The above picture explains the software stack architecture for an XTA
application: the Application Program interacts
with XA Resource Managers, like PostgreSQL and
MySQL, and with XTA.
XTA wraps LIXA libraries that
interact with the Resource Managers and implement
the client side part of the transaction management logic.
The simplest deployment of an XTA application consists of a single
Application Program that uses one or more
Resource Managers in a distributed transaction.
XTA connects to LIXA state server
(lixad) to coordinate the XA two phase
commit protocol.
Application Program,
Resource Managers and
LIXA state server don't have to reside in the
same system: they can be distributed in different systems that
communicate by mean of the TCP/IP protocol.
XTA allows deployment of multiple
Application Programs that use one or more
Resource Managers in a distributed transaction.
XTA connects to LIXA state server
(lixad) to coordinate the XA two phase
commit protocol.
Application Programs,
Resource Managers and
LIXA state server don't have to reside in the
same system: they can be distributed in different systems that
communicate by mean of the TCP/IP protocol.
Note
XTA implements the logic necessary to distribute a global transaction between two or more Application Programs but it does not provide the communication protocol between them. Using the above picture as an example, it's in charge of Application Program 1 to exchange information with Application Program 2: any synchronous or asynchronous protocol can be used.
Anyway, two constraints can't be violated:
all the Application Programs that participate in the same global transaction, must connect to the same LIXA state server
the Application Programs must call XTA functions in the proper order to participate in the same global transaction
XTA does not constraint many other aspects:
Application Programs don't have to be developed using the same programming language
Application Programs don't have to be executed inside the same sort of application container or server; example: one Application Program can be executed inside a shell script, another one can be executed under the supervision of an HTTP server
Application Programs can use any sort of communication channel to transfer the transaction identifier (XID): it can be REST over HTTP, it can be a message queueing system, it can be a POSIX pipe and so on. Any communication channel that can send an ASCII string is eligible for passing the transaction identifier (XID)
Application Programs can be called using consecutive calls or can run in concurrent branches
Important
Not all Resource Managers can be used in all the possible configurations that can be inferred from Figure 8.3, “Multiple applications layout”; further details will be provided in the next sections of this chapter.
XTA strongly depends from the type of XA support provided by the different Resource Managers and from the language bindings supplied with the Resource Managers' libraries. The following table is updated with the tested configurations: [43]
Table 8.1. Resouce Managers and Programming Languages for XTA
| Resource Manager | C | C++ | Java [a] | PHP[b] | Python |
|---|---|---|---|---|---|
| MySQL, MariaDB[c] | Y | Y | Y | - | Y[d] |
| Oracle DBMS | Y | Y | Y | N[e] | N[f] |
| PostgreSQL[g] | Y | Y | Y | - | Y[h] |
[a]
Every Resource Manager that supplies a proper
implementation of the
[b] Planned a SWIG wrapper, not yet implemented [c] “Multiple Applications, Consecutive Calls” pattern is not available because MySQL/MariaDB doesn't support TMSUSPEND and TMRESUME standard XA flags [e] No known way to re-use a standard OCI connection as an XA OCI connection; possibly not implementable [f] No known way to re-use a standard OCI connection as an XA OCI connection; possibly not implementable [g] “Multiple Applications, Consecutive Calls” pattern is not available because PostgreSQL doesn't support TMSUSPEND and TMRESUME standard XA flags | |||||
XTA support 4 different patterns:
“Single Application”: single Application Program with single or multiple Resource Managers as supported by the TX Transaction Demarcation Specification. An implementation example is described in the section called “The “Single Application” Pattern”.
“Multiple Applications, Consecutive Calls”: multiple Application Programs with single or multiple Resource Managers, only one Application Program is working as part of a transaction at a specified time, the XA global transaction is composed by a single transaction branch. An implementation example is described in the section called “The “Multiple Applications, Consecutive Calls” Pattern”.
“Multiple Applications, Concurrent Branches/Pseudo Synchronous”: multiple Application Programs with single or multiple Resource Managers, many Application Programs are concurrently working as part of a transaction at a specified time, the XA global transaction is composed by multiple transaction branches, the type of interaction among the Application Programs is “Pseudo Synchronous”. An implementation example is described in the section called “The “Multiple Applications, Concurrent Branches/Pseudo Synchronous” Pattern”.
“Multiple Applications, Concurrent Branches/Pseudo Asynchronous”: multiple Application Programs with single or multiple Resource Managers, many Application Programs are concurrently working as part of a transaction at a specified time, the XA global transaction is composed by multiple transaction branches, the type of interaction among the Application Programs is “Pseudo Asynchronous”. An implementation example is described in the section called “The “Multiple Applications, Concurrent Branches/Pseudo Asynchronous” Pattern”.
Important
This section refers to concepts that are linked with deep technical details of the [XAspec]: they are not trivial and sometimes they could even sound strange due to the epoch of XA standard design. XTA tries to provide an easy and modern interface for working with XA, but some caveats still remain at least for these reasons:
XA was designed as a protocol between one Transaction Manager and one or more Resource Managers; the designers probably didn't imagine the usage of XA inside something like XTA
XA standard predated the free software and open source initiatives and the design had to cope with commercial closed source softwares. Furthermore, XA didn't introduce changes in the proprietary protocols between Application Programs and Resource Managers, but “sidecar” approach was choosen.
Note
XTA is compatible with some interfaces (and classes) defined inside
the JTA (Java Transaction API) Version 1.2. Specifically, XTA
supports the Xid interface, it's compatible with
the XAException class and it's compatible with
classes that implement XAResource interface.
XTA is not an implementation of the JTA standard and it can't be used to replace a JTA implementation: XTA provides a different set of functions that are designed to support a different set of use cases. XTA reuses some interfaces and classes defined by JTA to leverage the huge amount of available JTA compliant Resource Managers.
[XAspec] defines the interface that must be
implemented by an “XA standard compliant”
Resource Manager: it's described in file
xa.h by struct xa_switch_t.
One tricky point is a consequence of xa_open()
and xa_close() functions: they must be called to
“open” and “close” the
Resource Manager.
Non XA applications use native functions to open and close the connections with the resource managers.
Application Programs that run in a XA context, must retrieve the connections with the Resource Managers previously opened by the Transaction Manager.
During LIXA development, 3 different type of Resource Managers have been discovered:
XA standard compliant Resource Managers that implement
xa_switch_tinterface and use the exact same functions to open a new connection and to retrieve a connection previously opened by the Transaction Manager: IBM DB2 and IBM MQ (previously MQSeries and WebSphere MQ) belong to this category [44]XA standard compliant Resource Managers that implement
xa_switch_tinterface and use different functions to open a new connection and to retrieve a connection previously opened by the Transaction Manager: Oracle Database Server belongs to this category [45]Non XA standard compliant Resource Managers that don't implement
xa_switch_tinterface and provide some XA equivalent functions by mean of special commands: MySQL[46], MariaDB and PostgreSQL belong to this category
The second type of Resource Managers is the most difficult to integrate from XTA perspective: next paragraphs explain why.
To cope with the different implementations of XA Resource Managers, XTA introduces a specific hierarchy for resources as depicted in the below image:
XAResource is an abstract class that can't be used to map a real Resource Manager, but useful to pass an object reference.
NativeXAResource is the concrete class that must be used for all the Resource Managers that provide XA standard interface.
AcquiredXAResource is a partially abstract class with basically no practical use (only conceptual).
MySQLXAResource is the concrete class that must be used for MySQL and MariaDB Resource Managers: it implements a specific constructor that accepts a MYSQL type connection.
PostgreSQLXAResource is the concrete class that must be used for PostgreSQL Resource Manager: it implements a specific constructor that accepts a PGconn type connection.
XtaJavaXAResource is a shadow class used to interface Java XAResource classes with XTA C libraries by mean of JNI (Java Native Interface). It's a type of resource the Application Program developer will never use.
Further non XA standard Resource Managers will require specialized somethingXAResource.
Due to the above explanation, the usage of the different XTA resource types present some differences:
NativeXAResource can be statically defined inside
lixac_conf.xmlor can be dynamically defined at run time using the class constructor.statically defined NativeXAResource must be created (method
new) after Transaction Manager object creationdynamically defined NativeXAResource must be created (method
new) before Transaction Manager object creationstatically defined NativeXAResource can be enlisted (method
enlist_resource), but it's not necessarydynamically defined NativeXAResource and AcquiredXAResource must be enlisted (method
enlist_resource) to participate in a distributed Transaction
XAResource must be created as standard
Java XAResource and must be enlisted with method
Transaction.enlistResource().
Java resources must be explicitly imported by the Application Program
and the necessary jar files must be put in
classpath as usual.
See the section called “Configuring Resource Managers for XTA Java” for additional information related to XTA for Java and Resource Managers.
XTA API Reference is extracted from source code using
Doxygen tool.
If you install doxygen, it will be produced
during build phase and stored in directory
doc/api/xta/html.
XTA API Reference can be consulted online:
C language: http://www.tiian.org/lixa/manuals/xta/C/
C++ language: http://www.tiian.org/lixa/manuals/xta/CPP/
Java language: http://www.tiian.org/lixa/manuals/xta/Java/
Python language: the client binding is produced by SWIG from the C++ interface; please look at C++ interface
[40] In the past, TX Transaction Demarcation Specification [TXspec], published in 1995 by X/Open, was designed for:
C and COBOL programming languages
single thread applications
applications executed under the control of TP Monitors
implicit (static) transactional context
Furthermore, TX conceptually relates to the DTP Reference Model Version 3 [RefModel], published in 1996 by X/Open, that was defined for:
applications executed under the control of TP Monitors
TP Monitors with integrated Transaction Managers
tight coupling between couples of Transaction Managers to propagate transactional contexts and to coordinated distributed transactions among different systems
[41] Under some circumstances, XTA can be used instead of JTA (Java Transaction API): it's not intended to be a JTA implementation or a JTA replacement, but it can be used as an alternative for some relevant use cases.
[42] Many authors consider two phase commit the root of every evil in the realm of massively distributed applications, but the author of XTA thinks that some specific use cases can take advantage from two phase commit transactionality
[43] Sometimes software versions make the difference, but this table don't cope with them and must not be intended like a compatibility and support matrix.
[44] IBM, DB2, MQ, MQSeries and WebSphere are trademarks of IBM™
[45] Oracle is a trademark of Oracle Corporation™
[46] MySQL is a trademark of Oracle Corporation™