Transactions originate from database management systems.

• Transaction is an execution of a program that accesses a database.

Transactional file servers 

• Transaction is an execution of a sequence of a client requests for file operations.

Transactions on distributed objects

• Transaction consists of the execution of a sequence of client requests.
• From client’s point of view, a transaction is a sequence of operations that forms a single step, transforming the server data from one consistent state to another.

Transaction can be provided as a part of middleware.

• CORBA provides the specification for Object Transaction Service with IDL interfaces allowing clients’ transactions to include multiple objects at multiple servers. 
  
  

  Figure 1: A client’s banking transaction
  

Atomic transaction

• All or nothing:
  • A transaction either completes successfully, in which case the effects of all of its operations are recorded in the objects, or (if it fails or is deliberately aborted) has no effect at all.
  • Failure atomicity – the effects are atomic even when the server crashes
  • Durability – after a transaction has completed successfully, all its effects are saved in permanent storage. 
• Isolation:
  • Each transaction must be performed without interference from other transactions.

• The intermediate effects of a transaction must not be visible to other transactions. 
  • ACID (atomicity, consistent, isolation, durability) properties
    
• Objects must be recoverable
  • To support the requirement for failure atomicity and durability
  • When a server process crashes unexpectedly due to hardware fault or a software error, the changes due to all completed transactions must be available in permanent storage so that when the server is replaced by a new process, it can recover the objects to reflect the all-or-nothing effect.
  • By the time a server acknowledges the completion of client’s transaction, all of the transaction’s changes to the objects must have been recorded in permanent storage. 
• Server must synchronize the operations to ensure that the isolation requirement is met.
• Doing this by performing the transactions serially – one at a time, in some arbitrary order.
• Transactions are allowed to execute concurrently if this would have the same effect as serial execution – serially equivalent or serializable.

Transaction capabilities can be added to servers of recoverable objects.

• Each transaction is created and managed by a coordinator, which implements the Coordinator interface.
• The coordinator gives each transaction an identifier (TID).
• Client invokes openTransaction method to introduce a new transaction – TID is allocated and returned.
• At the end of a transaction, the client invokes the closeTransaction method to indicates its end – all of the recoverable objects accessed by the transaction should have saved.
• If the client wants to abort a transaction, it invokes abortTransaction method – all of its effects should be removed. 
• A transaction is achieved by cooperation between a client program, some recoverable objects and a coordinator.
• Client specifies the sequence of invocations on recoverable objects, with the TID. 
  

  
  Figure 2: Operations in Coordinator interface
  

When transactions are provided as middleware, TID can be passed implicitly between openTransaction and closeTransaction or abortTransaction.

• CORBA Transaction Service

When the client makes a closeTransaction request

• If it has progressed normally, the reply states that the transaction is committed – all changes requested in the transaction are permanently recorded and that any future transactions that access the same data will see the results of all of the changes made during the transaction.
• Transaction may have to abort – conflicts with another transaction or crashing of a process or computer
• Recoverable objects and the coordinator must ensure that none of its effects are visible to future transactions, either in the objects or in their copies in permanent storage.

 A transaction is either successful or is aborted in one of two ways

• The client abort it (abortTransaction)
• Server aborts it. 

Server actions related to process crashes

• If a server process crashes unexpectedly
  • The server process will be replaced.
  • The new process aborts any uncommitted transactions and uses a recovery procedure to restore the value of the objects to the values produced by the most recently committed transaction. 
• To deal with a client that crashes unexpectedly during a transaction, servers give each transaction an expiry time and abort any transaction that has not completed before its expiry time.

Client actions related to server process crashes

• If a server crashes during transaction in progress, the client will become aware when one of the operations returns an exception after a timeout. 
• If a server crashes and is then replaced during the progress of a transaction, the transaction will no longer be valid and the client must be informed via an exception to the next operation.
  

  
  Figure 3: Transaction life histories