Warning:
JavaScript is turned OFF. None of the links on this page will work until it is reactivated.
If you need help turning JavaScript On, click here.
This Concept Map, created with IHMC CmapTools, has information related to: ch 13, Atomicity of transactions The atomicity has two aspects All or nothing: it either completes successfully, and the effects of all of its operations are recorded in the objects, or (if it fails or is aborted) it has no effect at all. This all-or-nothing effect has two further aspects of its own: 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 - there must be no observation by other transactions of a transaction's intermediate effects ???? to support durability and failure atomicity use recoverable objects record all changes before telling client transaction has committed to support isolation, use a form of synchronization we will define serial equivalence, The goal of transactions the objects managed by a server must remain in a consistent state when they are accessed by multiple transactions and in the presence of server crashes Recoverable objects can be recovered after their server crashes objects are stored in permanent storage Failure model transactions deal with crash failures of processes and omission failures of communication Designed for an asynchronous system It is assumed that messages may be delayed and Client cooperation by means of synchronizing server operations Clients share resources via a server e.g. some clients update server objects and others access them servers with multiple threads require atomic objects but in some applications, clients depend on one another to progress e.g. one is a producer and another a consumer e.g. one sets a lock and the other waits for it to be released it would not be a good idea for a waiting client to poll the server to see whether a resource is yet available it would also be unfair (later clients might get earlier turns) Java wait and notify methods allow threads to communicate with one another and to solve these problems e.g. when a client requests a resource, the server thread waits until it is notified that the resource is available, Failure model for transactions Lampson’s failure model deals with failures of disks, servers and communication. algorithms work correctly when predictable faults occur. but if a disaster occurs, we cannot say what will happen Writes to permanent storage may fail e.g. by writing nothing or a wrong value (write to wrong block is a disaster) reads can detect bad blocks by checksum Servers may crash occasionally. when a crashed server is replaced by a new process its memory is cleared and then it carries out a recovery procedure to get its objects’ state faulty servers are made to crash so that they do not produce arbitrary failures There may be an arbitrary delay before a message arrives. A message may be lost, duplicated or corrupted. recipient can detect corrupt messages (by checksum) forged messages and undetected corrupt messages are disasters ???? Some applications require a sequence of client requests to a server to be atomic in the sense that: they are free from interference by operations being performed on behalf of other concurrent clients; and either all of the operations must be completed successfully or they must have no effect at all in the presence of server crashes. Transactions originate from database management systems Transactional file servers were built in the 1980s Transactions on distributed objects late 80s and 90s Middleware components e.g. CORBA Transaction service. Transactions apply to recoverable objects and are intended to be atomic., The goal of transactions the objects managed by a server must remain in a consistent state when they are accessed by multiple transactions and in the presence of server crashes Recoverable objects can be recovered after their server crashes objects are stored in permanent storage Failure model transactions deal with crash failures of processes and omission failures of communication Designed for an asynchronous system It is assumed that messages may be delayed and Atomic operations at server first we consider the synchronisation of client operations without transactions when a server uses multiple threads it can perform several client operations concurrently if we allowed deposit and withdraw to run concurrently we could get inconsistent results objects should be designed for safe concurrent access e.g. in Java use synchronized methods, e.g. public synchronized void deposit(int amount) throws RemoteException atomic operations are free from interference from concurrent operations in other threads. use any available mutual exclusion mechanism, to support durability and failure atomicity use recoverable objects record all changes before telling client transaction has committed to support isolation, use a form of synchronization we will define serial equivalence in which Atomicity of transactions The atomicity has two aspects All or nothing: it either completes successfully, and the effects of all of its operations are recorded in the objects, or (if it fails or is aborted) it has no effect at all. This all-or-nothing effect has two further aspects of its own: 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 - there must be no observation by other transactions of a transaction's intermediate effects, Concurrency control (12.2.1) We will illustrate the ‘lost update’ and the ‘inconsistent retrievals’ problems which can occur in the absence of appropriate concurrency control a lost update occurs when two transactions both read the old value of a variable and use it to calculate a new value inconsistent retrievals occur when a retieval transaction observes values that are involved in an ongoing updating transaction we show how serial equivalent executions of transactions can avoid these problems we assume that the operations deposit, withdraw, getBalance and setBalance are synchronized operations - that is, their effect on the account balance is atomic. and Serial equivalence if each one of a set of transactions has the correct effect when done on its own then if they are done one at a time in some order the effect will be correct a serially equivalent interleaving is one in which the combined effect is the same as if the transactions had been done one at a time in some order the same effect means the read operations return the same values the instance variables of the objects have the same values at the end, Some applications require a sequence of client requests to a server to be atomic in the sense that: they are free from interference by operations being performed on behalf of other concurrent clients; and either all of the operations must be completed successfully or they must have no effect at all in the presence of server crashes. Transactions originate from database management systems Transactional file servers were built in the 1980s Transactions on distributed objects late 80s and 90s Middleware components e.g. CORBA Transaction service. Transactions apply to recoverable objects and are intended to be atomic. that contain Atomicity of transactions The atomicity has two aspects All or nothing: it either completes successfully, and the effects of all of its operations are recorded in the objects, or (if it fails or is aborted) it has no effect at all. This all-or-nothing effect has two further aspects of its own: 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 - there must be no observation by other transactions of a transaction's intermediate effects, Concurrency control (12.2.1) We will illustrate the ‘lost update’ and the ‘inconsistent retrievals’ problems which can occur in the absence of appropriate concurrency control a lost update occurs when two transactions both read the old value of a variable and use it to calculate a new value inconsistent retrievals occur when a retieval transaction observes values that are involved in an ongoing updating transaction we show how serial equivalent executions of transactions can avoid these problems we assume that the operations deposit, withdraw, getBalance and setBalance are synchronized operations - that is, their effect on the account balance is atomic. and Recoverability from aborts (12.2.3) if a transaction aborts, the server must make sure that other concurrent transactions do not see any of its effects we study two problems: ‘dirty reads’ an interaction between a read operation in one transaction and an earlier write operation on the same object (by a transaction that then aborts) a transaction that committed with a ‘dirty read’ is not recoverable ‘premature writes’ interactions between write operations on the same object by different transactions, one of which aborts (getBalance is a read operation and setBalance a write operation), Atomicity of transactions The atomicity has two aspects All or nothing: it either completes successfully, and the effects of all of its operations are recorded in the objects, or (if it fails or is aborted) it has no effect at all. This all-or-nothing effect has two further aspects of its own: 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 - there must be no observation by other transactions of a transaction's intermediate effects ???? Concurrency control (12.2.1) We will illustrate the ‘lost update’ and the ‘inconsistent retrievals’ problems which can occur in the absence of appropriate concurrency control a lost update occurs when two transactions both read the old value of a variable and use it to calculate a new value inconsistent retrievals occur when a retieval transaction observes values that are involved in an ongoing updating transaction we show how serial equivalent executions of transactions can avoid these problems we assume that the operations deposit, withdraw, getBalance and setBalance are synchronized operations - that is, their effect on the account balance is atomic., Atomic operations at server first we consider the synchronisation of client operations without transactions when a server uses multiple threads it can perform several client operations concurrently if we allowed deposit and withdraw to run concurrently we could get inconsistent results objects should be designed for safe concurrent access e.g. in Java use synchronized methods, e.g. public synchronized void deposit(int amount) throws RemoteException atomic operations are free from interference from concurrent operations in other threads. use any available mutual exclusion mechanism ALSO Failure model for transactions Lampson’s failure model deals with failures of disks, servers and communication. algorithms work correctly when predictable faults occur. but if a disaster occurs, we cannot say what will happen Writes to permanent storage may fail e.g. by writing nothing or a wrong value (write to wrong block is a disaster) reads can detect bad blocks by checksum Servers may crash occasionally. when a crashed server is replaced by a new process its memory is cleared and then it carries out a recovery procedure to get its objects’ state faulty servers are made to crash so that they do not produce arbitrary failures There may be an arbitrary delay before a message arrives. A message may be lost, duplicated or corrupted. recipient can detect corrupt messages (by checksum) forged messages and undetected corrupt messages are disasters