Professional Documents
Culture Documents
CNET343 L18 Transactions
CNET343 L18 Transactions
CNET343 L18 Transactions
Context
A pervasive class of applications in which users read and update structured data in a shared database
Air-line reservation systems On-line banking The UoP student record system The Voyager system in the UoP Library. Not necessarily huge - dental booking system
Often distributed Many large hardware and software vendors get most of their revenue from TP
Characteristics
Concurrent access to DB Often mission critical for organisation End users are not computer professionals Implemented with lots of redundancy Recovery from failures should not involve the end users it should be centrally controlled and, as automatic as possible Performance and Resilience are crucial
withdraw this amount from the account deposit this amount into the account return the balance in the account
Idea of a Transaction
Transactions consist of several operations which must all be carried out or none
Buying a house
Purchasing a series of air ights when no direct route exists You dont want to be stranded in Anchorage
TP System Infrastructure
Users viewpoint Enter a request from a browser or other display device The system performs some application-specic work, which includes database accesses Receive a reply (usually, but not always) The TP system ensures that each transaction Is an independent unit of work Executes exactly once Produces permanent results TP system makes it easy to program transactions TP system has tools to make it easy to manage
Would expect that the bank - where all accounts a,b,c are held, sees no change in the total funds it holds
TP System Infrastructure
End-User Front End Program Request Controller (routes requests and supervises their execution) Transaction Server Database System Client
Transactions
Regard each transaction as a set of operations that must all be carried out or none unacceptable to have a partially successful transaction Many separate transactions must be processed efciently - hence concurrently. But this leads to potential conict and must be done carefully Like revisiting the synchronisation issue at a coarser level of granularity
Back-End (Server)
Single or Nested
Sometimes - especially in more complex distributed systems, transactions can be composed of subtransactions. When the original model is meant - say at transaction Known as nested transactions - when a subtransaction aborts, the parent may attempt a different subtransaction, or may record the fact and then commit. It need not fail. Nested distributed transactions offer more potential parallelism
ACID
Atomicity: Either all operations are carried out, or none.
Consistency: Each transaction transforms the system from a consistent & valid state to another consistent & valid state. It must be impossible for any transaction to leave the system in an invalid state. eg wrong total $ in bank
Isolation: The execution of each transaction must be isolated from the execution of other transactions Durability: Once a transaction is completed, the system guarantees that the results of its operations will persist
Atomicity
Clear based on the examples so far More examples? ATM - issue 100, debit the account Atomicity will be enforced by the TP system
Consistency
Means internal consistency of the DB The DB must satisfy all its integrity constraints
unique primary keys, no dangling references total in bank, salary inside a range
Isolation
Technically this means that transactions run in an order that is serially equivalent The DB gives the illusion that the transactions are being done one after another, but in fact are run in parallel and locks are uses to prevent conict Supported by the TP system
Durability
You expect that the bank will remember how much is in your account even though you dont use it for 3 months At the end, all the updates will be in stable storage that will survive power or OS failure Necessary for the transaction to have legal status Usually achieved with log les Supported by the TP system
Inside a TP System
How are the ACID properties supported? For non-distributed transactions, mainly by the database
Concurrency
Servers must isolate transactions and not allow them to interfere One way would be to perform each transaction in the order it arrived ie serially A performance disaster Must run them concurrently - especially as each transaction usually involves I/O (disk access) and the processor is idle during this time
Serial Equivalence
Run the transactions concurrently, but for consistency insist the the effect is equivalent to serial execution serialisable (compare with on-the-wire format = serialisable data structure) Examples of typical problems when transactions are not serial equivalent
Concurrency Examples
Three accounts
T transfers from a to b so as to increase balance in b by 10% U transfers from c to b so as to increase balance in b by 10% Expect nal balance in b to be 200+20+22=242$
Transaction U: balance = b.getBalance(); b.setBalance(balance*1.1); c.withdraw(balance/10) balance = b.getBalance(); b.setBalance(balance*1.1); $200 $220
TransactionT: balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) balance = b.getBalance() $200 b.setBalance(balance*1.1) $220
b.setBalance(balance*1.1); a.withdraw(balance/10)
Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012
Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012
Exclusive Locks
The server attempts to lock any object that is about to be used in the transaction The lock can only be held by one process, and if it is held, other processes must wait for it to become free The use of the locks effectively serialises the transactions - to ensure this, a transaction is not allowed to request new locks after it has released any
openTransaction bal = b.getBalance() lock B b.setBalance(bal*1.1) a.withdraw(bal/10) closeTransaction lock A unlockA, B lock B b.setBalance(bal*1.1) c.withdraw(bal/10) lock C closeTransaction unlockB, C openTransaction bal = b.getBalance() waits for Ts lock on B
Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012
Deadlock
The use of locks can lead to deadlock Imagine a cycle where each process is waiting for the one in front to release a lock There are software methods for detecting deadlock - in which case the deadlock can be broken somehow - but hard to do this efciently
Lock Granularity
Lock the whole database, a single object, the row of a DB? How long is the bit of code protected by the lock? For efciency want it to be short, but this leads to more complex programming Think of Java synchronized blocks compared with synchronized methods
Drawbacks of Locking
Locking is overly restrictive on the degree of concurrency Deadlocks produce unnecessary aborts Lock maintenance is an overhead that may not be required Known as a Pessimistic approach
Early WWW
To support processing of transactions arriving over the WWW application servers were invented to ease the programmers job
But very quickly they both evolved into combined functionality of app servers and TP monitors All happening at the same time as MOM for enterprise integration, Web services and SOA fashion. Large Dist Sys combine parts of all these
Application Servers
The term middleware is not usually used in this context - but TP infrastructure plays the same role as middleware in other distributed systems Programmer writes an app to process a single request. App Server scales it up to a large, distributed system Enterprise Java Beans, IBM Websphere, Microsoft .NET (COM+), Oracle Weblogic and Application Server
IBM CICS
1969 originally for Public Utility companies who wanted their telephone staff to be able to make real time changes to customer data and not to have to wait for overnight batch jobs to run Development moved to Hursley UK in 1974 Runs on z/OS mainframes and is very deeply entwined with the OS (ran efciently on 32kB RAM) Long history and commercial importance of proven performance and resilience
CICS
90% of Fortune 500 companies still use CICS on z/OS mainframes for core business Can still program it in Cobol, but now has all the modern connectivity - EJB, Web services etc Some modularity that ts with the mainframe hardware
Summary
Idea of a Transaction, ACID Some idea about this mysterious bit of software kit besides the OS, DB, network and application Performance and Resilience are crucial