A TP Monitor is a subsystem that groups together sets of related database updates and submits them together to a relational database. The result is that the database server does not need to do all of the work of managing the consistency/correctness of the database; the TP Monitor makes sure that groups of updates take place together or not at all. The advantages of this include increased system robustness as well as throughput.
This also supports the four transaction processing ACID requirements:
All transactions are either performed completely - committed, or are not done at all; a partial transaction that is aborted must be rolled back.
The effects of a transaction must preserve required system properties. For instance, if funds are transferred between accounts, a deposit and withdrawal must both be committed to the database, so that the accounting system does not fall out of balance.
In double-entry accounting, the "staying in balance" property is usually not overly difficult to maintain. The more thorny issue comes when the property is something like Cash Balance Cannot Drop Below Zero, or We can't ship out inventory we don't have. In such cases, if you have two transactions being submitted concurrently, it could be that either could be accepted, but not both. If one of the transactions would cause balance requirements to be violated, the TP monitor therefore needs to reject one of the transactions.
Intermediate stages must not be made visible to other transactions. Thus, in the case of a transfer of funds between accounts, both sides of the double-entry bookkeeping system must change together for each transaction. This means that transactions appear to execute serially (e.g. in order) even if some of the work is done concurrently.
Once a transaction is committed, the change must persist, except in the face of a truly catastrophic failure.
If Mongol hordes ride through and lay waste to your server room, you can't expect the TP monitor to help keep transactions persistent! But it should be resistant to reasonably traumatic sorts of system failures such as a network link breaking down or perhaps even a disk drive malfunctioning.
TP Monitors and other Database Middleware lists some of the "big names" in the area.
X/Open CAE Specification : Distributed Transaction Processing:CPI-C Spec, Version 2
Open Group Documentation Set: Transaction Processing - Six Volume Set
Distributed TP: The XA Specification
XA is critical to the construction of distributed transaction processing systems; it represents a standardized API by which transaction management software can communicate with a DBMS and achieve the ACID properties. The really cool thing that XA supports is the ability to achieve these properties even across multiple databases.
XA is supported by major relational database systems such as Oracle , Informix , Sybase, DB2 , amongst others; support for XA is conspicuously absent for the popular "open source" databases, PostgreSQL and MySQL.
What functionality (if any) of TUXEDO is lost when connecting to a non-XA compliant database? indicates how the lack of XA support prevents the ability to provide ACID transactional guarantees.
Distributed TP: The TX (Transaction Demarcation) Specification
Atomic Transactions Theory: Beyond TP:C and T
3-Tier Client/Server at Work Examples using Tuxedo
The Tuxedo System: Software for Constructing and Managing Distributed Business Applications
XA Documentation from various sources...
There are several vendors that offer commercial TP solutions that appear to run on Linux.
Tecco - Middleware system - distinct from CORBA/DCOM
Elvin is a publish-subscribe notification service where consumers use content-based addressing to select notifications of interest. It parallels the CORBA Notification Service moreso than it does the Transaction Service.
Elvin is available in source code form, and is freely available for noncommercial use. The authors are considering making it available under some form of Open Source license.
I have been working for some months on an implementation of the CORBA transaction service. It is licensed under the terms of the GNU GPL and is called the GNU Transaction Server. The core is done; all that remains is to finish up the commit logic and it will be done. Unfortunately, due to a sudden upswing in the amount of work I have at my job, I find myself recently without as much time as I would like to work on the project. Therefore, I am pre-announcing it and making the quasi-working code available for others to investigate and, if the fancy strikes them, help finish. This is not (really) working code, and only developers will probably be interested in it. It is implemented in C using ORBit. It is single-threaded, although I am interested in multi-threading it in the future. It compiles without warnings at this point and will even, after a fashion, commit transactions; the Terminator interface is the only one with any work left to do. Interested parties may access the code via CVS as follows: export CVSROOT=":pserver:anonymous@rocinante.mspring.net:/cvsroot" cvs login CVS password: (just press 'RETURN' here) % cvs checkout gts Discussion should occur on the mailing list. To subscribe: echo "subscribe gts-list" | mail majordomo@lists.mindspring.com After the core is working, I am interested in implementing the Current interface with ORBit and cooperating with any other free ORBs who would like a Current interface which works with GTS. I would also like to implement the Java transaction service, which is fairly straight mapping of the CORBA transaction service. (In the distant future, I am interested in supporting The X/Open transaction service, and I have a copy of the XA, et al., specs, but they are really different enough that I wonder if it might not need to be a separate project. Most of the work there would be in implementing TxRPC, I think, but I don't know, as I really haven't given it much serious thought.) Anyway, if anyone wants to give it a whirl and maybe spend a little time helping out, we could all come out of the experience with a free transaction server, and I think that that would be cool. Please let me know if I may be of assistance. | ||
| --Todd Graham Lewis | ||
Seeks to be a close analogue to Tuxedo, implementing XA and XATMI standards, intended to be able to be a drop-in replacement for Tuxedo.
Documentation findable externally at Endurox.org
Note that there also exist Message Queueing Systems systems that are not, precisely speaking, TP monitors, but which offer analogous assistance in improving reliability and scalability. They tend to suffer somewhat on the "consistency" side of things; several messages may be required to complete an overall transaction, and those messages will each tend to reflect the latest system state rather than consistently looking back to the state of the system at the time the transaction began to take place.
Isect is a free software message queueing package that is available.
SDTP - A Multilevel-Secure Distributed Transaction Processing System
Uses CMUCL , FreeBSD , PostgreSQL, the X/Open DTP transaction architecture.
BEA sells a primarily Unix-based product, Tuxedo, that is highly regarded.
BEA have released a "demo" edition gratis for developers to play with.