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: ch13 tran tran, Failure model transactions deal with crash failures of processes and omission failures of communication contains 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, Transactions contains Operations of the Account interface deposit(amount) deposit amount in the account withdraw(amount) withdraw amount from the account getBalance() amount return the balance of the account setBalance(amount) set the balance of the account to amount, Transactions contains 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, 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 contains 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 (e.g. mutex), Operations of the Branch interface create(name) account create a new account with a given name lookUp(name) account return a reference to the account with the given name branchTotal() amount return the total of all the balances at the branch contains Operations of the Account interface deposit(amount) deposit amount in the account withdraw(amount) withdraw amount from the account getBalance() amount return the balance of the account setBalance(amount) set the balance of the account to amount, Recoverable objects can be recovered after their server crashes objects are stored in permanent storage contains 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, Designed for an asynchronous system It is assumed that messages may be delayed contains 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, Transactions contains 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 (e.g. mutex), Failure model transactions deal with crash failures of processes and omission failures of communication contains 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