A LIXA system is the assembling of two components: the client and the server. The figure below shows a typical configuration with one Application Program and two Resource Managers.
The model shows logical and "phisycal" blocks:
"Application Program code" is the code of your own application
"librm1" is the code of the library your application must use to communicate with "RM1" (the first resource manager)
"librm2" is the code of the library your application must use to communicate with "RM2" (the second resource manager)
"liblixac" is the code of the library your application must use to invoke the TX verbs and send instruction to the Transaction Manager
"Application Program code" + "librm1" + "librm2" + "liblixac" must be linked togheter to produce the Application Program; the Application Program is an executable object
"RM1" is the first resource manager; it may be a relational database (RDBMS)
"RM2" is the second resource manager; it may be an object oriented database (OODBMS)
"lixad" is the daemon used by "liblixac" to store the states of the transactions
The model shows how the blocks communicate:
(A1): is the protocol supplied by the first resource manager; SQL/CLI is an example and is supplied by IBM DB2, SQL/OCI is another example and is supplied by Oracle Database Server
(B1): is the protocol supplied by the second resource manager; every resource manager has its own protocol and its own API
(A2): is the internal protocol used by the client of RM1 to communicate with RM1 server process(es); it can be a cross memory or a network protocol and it depends on RM1 configuration
(B2): is the internal protocol used by the client of RM2 to communicate with RM2 server process(es); it can be a cross memory or a network protocol and it depends on RM2 configuration
(TX): is the protocol supplied by the LIXA project and is described in [TXspec]; it's a standard protocol and API
(XA): is the standard protocol used by the LIXA project to communicate with the resource managers and is described in [XAspec]; it's a standard protocol and API
(LX): is the internal protocol used by the client of LIXA to communicate with the LIXA server process (lixad); it is a network protocol
The lixad daemon process can be executed on any system: there is no need to execute it on the same system that's hosting the Application Programs. The communications between the client and the server (lixad) uses TCP/IP sockets.
The lixac library is
embedded in the Application
Programs; the communication between the Application Program and
the lixac library uses
TX (Transaction Demarcation)
API, see [TXspec].
The lixac
library contains all the logic of the LIXA Transaction Manager.
The communication between the Application Program and the Resource
Managers depends on Resource Managers type and configuration:
it may be cross memory, TCP/IP, System V IPC, etc...
The communication between the
lixac library and the
Resource Manager depends on Resource Manager configuration and must be
of the same used by the Application Program.
The communication between
lixac library and
lixad is ever istantiated by the client: the
server never calls the clients.
This section explains some different deployment models you can set up leveraging the LIXA project technology.
The easiest non trivial deployment of a distributed transaction processing system based on the LIXA project is showed below: a single node hosts the Application Program, the Resource Managers and the LIXA server.
A trivial deployment of a distributed transaction processing system based on the LIXA project is showed below: a single node hosts the Application Program, the Resource Manager and the LIXA server. This configuration is obtained from the previous one removing a Resource Manager.
Using only one Resource Manager is supported by the LIXA project technology, but it's quite useless because you don't need a transaction manager to perform single phase commit against one Resource Manager. This type of configuration will not be described more deeply.
A fully distributed transaction processing system can be achieved hosting every component in a different node. The picture below shows 4 different nodes:
an application server node hosting the Application Program
a Transaction Manager dedicated node hosting the LIXA server
two Resource Manager dedicated nodes hosting the Reosurce Managers
A more complex distributed transaction processing system can be achieved introducing a second application server and a third Resource Manager; in the picture below the third Resource Manager is hosted in the same node of the second Resource Manager.
The two different Application Programs do not need to be hosted in different application servers. They are different Application Programs because they use a different mix of Resource Managers.
Further complexity can be reached introducing an Application Program that uses three (or more) different Resource Managers, but this document will not go on this path to preserve understandability [16] .