In computer programming, a transaction means a sequence of information exchange (database updates) where data integrity is ensured. 

ATOMICITY

All, or Nothing

CONSISTENCY

From one valid state to another valid state

ISOLATION

Transactions do not affect each other

Isolation levels (relaxation):

READ_UNCOMMITED < READ_COMMITED < REPEATEBLE_READ <SERIALIZABLE

DURABILITY

Stored permanently

A transaction in which two and more transactional resources are involved


DT, as any other transactions, must have all four ACID properties

Transactional resources?

• Databases
• JMS
• EIS (Enterprise Integration Systems supporting transactions)

How IS ACID achieved?

Transaction manager is component that is responsible for coordinating of distributed transactions. 

Transaction manager uses two-phase commit protocol to perform atomic distributed transactions.

An algorithm ensuring correct completion of a distributed transaction = Atomicity

It coordinates all participated transactional resources within distributed transaction on whether to commit or rollback (abort).

Answer NO or no answer causes rollback of DT. 

If the transaction will commit, the transaction coordinator records the decision on stable storage, and the protocol enters phase II. 

If the transaction will abort all participant are informed about this decision too.

Transaction log is used for transaction recovery in case of failure.

If a distributed transaction will commit, transaction coordinator writes the decision to log.

Each participant must have own transaction log to write commit decision.

One-phase

If there is only one involved transactional resouce, transaction manager can use simply commit

last resouce gambit

It is possible to enlist one resource which is not two-phase commit aware.

The Open Group standard for Distributed Transaction Processing (DTP)

= standard for distributed transactions

The standard describes how the transaction manager must behave to coordinate distributed transaction and what resource managers of transactional resources must do to support transactional access.

XA Transaction = Distributed Transaction

XA Resource = Transactional Resource (Participant)

JTA is java implementation of X/OPEN XA specification

JTA specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.

• High-level application interface for transaction boundaries demarcation
• High-level transaction manager interface used by container to control transactions

JTA is a specification developed under the Java Community Process as JSR 907. 

JTS is implementation of another specification: Object Transaction Service (OTS) specified by OMG

JTS specifies an implementation of a transaction manager that support JTA specification = JTS can be used by JTA

JTS uses the standard CORBA ORB/TS interfaces and Internet Inter-ORB Protocol (IIOP) for transaction context propagation between JTS transaction managers.

JTA is high-level API

JTS is low-level API

javax.transaction.UserTransaction

javax.transaction.TransactionManager

javax.transaction.Transaction

javax.transaction.Synchronization

javax.transaction.xa.XAResource

javax.transaction.xa.Xid

Used by JEE applications to programmatically demarcate transactions

Obtained via JNDI (java:jboss/UserTransaction) or using @Inject annotation (JEE)

Operations:

begin() creates a new transaction and associate it with the current thread

commit() completes the transaction associated with current thread

rollback() rollback the transaction associated with current thread

setRollbackOnly() only possible outcome of the transaction of current thread is rollback

getStatus() obtain the status of the transaction associated with current thread

Used by Java container

Obtained via JNDI (java:jboss/TransactionManager)

Operations:

begin() creates a new transaction and associate it with the current thread

commit() completes the transaction associated with current thread

rollback() rollback the transaction associated with current thread

setRollbackOnly() only possible outcome of the transaction of current thread is rollback

int getStatus() obtain the status of the transaction associated with current thread

Transaction getTransaction() gets the transaction of the calling thread

Transaction suspend() suspend transaction of the calling thread

resume(Transaction t) resumes the transaction context of the calling thread with t

Represents transaction started by transaction manager

Controls transaction outcome: commit, rollback, setRollbackOnly

Enlists/delists resources to transaction

Registers synchornizations with transaction

Operations:

commit() completes the transaction associated with current thread

rollback() rollback the transaction associated with current thread

setRollbackOnly() only possible outcome of the transaction of current thread is rollback

enlistResource(XAResouce xar) enlist the specified resource to transaction

delistResource(XAResouce xar, int flag) delist the specified resource from transaction

registerSynchronization(Synchronization sync) registers synchronization

Callback interface to inform about transaction completion

Typically used by cache to update/invalidate its contents

Best-effort only, not guaranteed to be called in case of crash

Operations:

beforeCompletion()

afterCompletion()

Represents any object that supports one or two phase protocol to participate in transaction and can ensure ACID properties

• Database connection
• JMS connection

Operations (called exclusively by TransactionManager):

start(Xid xid, int flag) starts the work on behalf of transaction branch specified in xid 

end(Xid xid, int flag) ends the work performed on behalf of transaction branch

prepare(Xid xid) asks the resource manager to prepare

commit(Xid xid, boolean onePhase) commit

rollback(Xid xid) rollback

Xid[] recover(int flag) obtains a list of prepared transaction branches from RM

forget(Xid xid) tells the resource manager to forget about a heuristically completed transaction branch

Unique identifier of transaction

Industry standard

• Fully portable across different Transaction Managers, allows creation of delegated transactions in case of hierarchical Transaction Managers

Consists of three components

• Format identifier – must be unique across the transaction systems
• Global transaction identifier
• Branch qualifier

Common atomic transactions are short-running

= short atomic operations

For Web Services, we need long-running transaction which are propagated between communicating Web Service.

BEA, IBM, and Microsoft developed WS-Coordinator and WS-Tx specs.

WS-Tx was split to WS-Atomic Transaction ans WS-BusinessActivity.

There is a need for a coordination infrastructure in a Web Service environmen.

WS-Coordinator defines a framework that allows different coordination participant to be plugged-in to coordinate work between clients, services and participans.

Consists of three main modules:

• Activation Service    Installation of a new coordinator
• Registration Service    Registration of participant with the coordinator
• Context    Contains information necessary to perform coordination, context is propagated between participants