B2B Integration : A Practical Guide to Collaborative E-commerce

Middleware Technologies 217
Isolation — A transaction's behavior is not affected by other transactions
which are occurring concurrently. This is often accomplished by
serializing transactions by using table or row level locking within a
database.
Durability — A transaction's effects are permanent after it commits,
even in the event of a system failure.
TP monitors allow multi-vendor resources to plug into the TP system
and provide global management of transactions across databases and
other resources. TP monitors are still unmatched in the management of
high transactional environments across multiple database systems residing
on multiple operating systems.
8.2.1. How they work?
TP monitors decouple the relationship between the client application
and the physical database schema. Access to the underlying database is
usually through an API, ensuring enforcement of business rules and
referential integrity. By offloading most work to a middle tier, TP
monitors improve overall system efficiency.
TP monitors work by creating classes or application processes,
which are memory-resident threads that handle the work for a particular
application. Each application can have one or more classes
belonging to it. When a client requests a service from the TP monitor,
the server loads the DLL for the process, manages the execution of the
process or transaction and returns the results to the client. The DLL can
then remain resident in memory where it can be shared by other
processes.
Due to the inherently heterogeneous environment in which TP
monitors exist, a set of standards was developed to allow these products
to communicate with disparate systems. In 1991, the X/Open XTP group
published the Transaction Processing Reference Model, often referred
to as the X/Open XA model for transaction managers.
The standard defined three components for transaction processing
are: