Locking

• In a distributed transaction, the locks on an object are held locally (in the same server). 
• Local lock manager can decide whether to grant a lock or make the requesting transaction wait. 
• It cannot release any locks until it knows that the transaction has been committed or aborted at all the servers involved in the transaction. 
• As lock managers in different servers set their locks independently of one another, it is possible that different servers may impose different ordering on transactions.
• These different orderings can lead to cyclic dependencies between transactions, giving rise to a distributed deadlock situation. 
• When deadlock is detected, a transaction is aborted to resolve the deadlock. 
  
  

Timestamp ordering concurrency control

• In distributed transactions, each coordinator issue globally unique timestamps. 
• A globally unique transaction timestamp is issued to the client by the first coordinator accesses by a transaction. 
• The transaction timestamp is passed to the coordinator at each server whose objects perform an operation in the transaction. 
• The servers of distributed transactions are jointly responsible for ensuring that they are performed in a serially equivalent manner. 
• For reason of efficiency, the timestamp issued by one coordinator is roughly synchronized with those issued by the other coordinators. 
• In this case, the ordering of transaction is corresponds to the order in which they are started in real time. 
• Timestamp can be kept roughly synchronized by the use of synchronized local physical clock. 

Optimistic concurrency control

• A distributed transactions is validated by a collection of independent servers, each of which validates transactions that access its own objects. 
• Validation protocol: only one transaction may perform validation and update phases at a time. 
  • Server might be unable to validate the other transaction until the first one has completed.
  • Might lead to commitment deadlock
• Kung and Robinson [1981] proposes parallel validation
• Allow multiple transactions to be in the validation phase at the same time.
• Transactions will not suffer from commitment deadlock. 
• If servers perform independent validations, it is possible that different servers in a distributed transaction may serialize the same set of transactions in different orders.

To prevent this – local validation at each server, then global validation is carried out. 

Another approach: all of the servers of a particular transaction use the same globally unique transaction number at the start of the validation.