Transactions ECEN 5053 Software Engineering of Distributed Systems University of ColoradoTransactionsTransactions: continuedSlide 4Multi-Threaded ProgrammingJava ThreadsJava Threads (cont.)Thread & RunnableSimple Thread ExampleThread SafetyThread Safety (cont.)Slide 12Slide 13The Synchronized KeywordJava’s Class ThreadJava Thread Life Cycle (State Diagram)Join ExampleJoin Example (cont.)Slide 19Wait & NotifyAllWait & NotifyAll (cont.)Slide 22Deadlock & LivenessDeadlock & Liveness (cont.)Multi-Threaded Programming : SummaryThe Tahiti SyndromeOptimistic vs. Pessimistic Concurrency ControlSlide 28Transactions are EverywhereTransactionsECEN 5053Software Engineering of Distributed SystemsUniversity of ColoradoOriginally prepared by: David LeberknightTransactions - 2Originally prepared by: David Leberknight TransactionsAll robust “transactions” support these so-called ACID properties:Atomicity (indivisible unit of work) –All or nothing.Consistency (leaves system in a stable state) –If this cannot be done, the transaction will abort.Isolation (not affected by other transactions that execute concurrently)–Requires a locking strategy.Durability (effects are permanent after commit)–Implies persistent storage, such as a database.Example:TransactionManager.beginTransaction( )CheckingAccount.debit( $1000 )SavingsAccount.credit( $1000 )TransactionManager.commitTransaction( )Transactions - 3Originally prepared by: David Leberknight Transactions: continuedThis seems easy… so what’s the big deal?The concept is straight-forward, but the implementation can be tricky.Distributed system design is hard!Multi-threaded programming is much more difficult than single-threaded programming.The system must be fault tolerant (highly available?). Crashes happen.Objects must outlive the programs that created them, and they must survive system crashes (persistence).Messages can get lost.Multiple processes execute in parallel on different machines; this requires concurrency control.Other issues: load balancing, automatic failover, security, ...Transactions - 4Originally prepared by: David Leberknight Transactions: continuedTransactions are absolutely essential!Imagine life without them…No Atomicity: half-completed operationsNo Consistency: bogus object statesNo Isolation: corruption due to multi-threaded interactions also: dirty reads / lost updatesNo Durability: crash and lose everythingIn other words, computing systems would simply be unreliable.Transactions - 5Originally prepared by: David Leberknight Multi-Threaded ProgrammingBefore we get into the nitty-gritty detail of how real world systems (such as DBMSs) implement transactions, it will help to review the basics of multi-threaded programming.We will use Java to illustrate these concepts.Transactions - 6Originally prepared by: David Leberknight Java ThreadsA Thread is an execution process.Only one thread at a time may be “running” on a single processor machine at any given time.In an environment that supports multi-threading, significant efficiencies and design elegance can be gained by careful use of Threads (multiple concurrent flows of control through the program).Java provides excellent support for Threads, but there are significant holes.Multi-threaded programming is hard to get right.For a good Java reference, see: Concurrent Programming in Java - Design Principles & Patterns (2nd Ed.) Doug Lea, Addison Wesley 1996. <ISBN 0-201-31009-0>Transactions - 7Originally prepared by: David Leberknight Java Threads (cont.)Threads are indispensable …for user interfaces that must remain responsive while simultaneously computing some result.for servers with more than one simultaneous client.for polling loops (if necessary).for increased parallel-processing performance.when modeling a naturally concurrent, parallel, or asynchronous situation.Transactions - 8Originally prepared by: David Leberknight Thread & RunnableMulti-Threaded programming is hard despite the java.lang.Thread class and the java.lang.Runnable interface, which have relatively easy syntax:public interface Runnable { public abstract void run();}public class Thread ...{ public Thread( Runnable runner ) { … } public synchronized void start() { … } // calls runner’s run() ...}Transactions - 9Originally prepared by: David Leberknight Simple Thread Exampleclass ThreadTest { public static void main( String[] args ) { Thread t = new Thread( new WorkerProcess( ) ); System.out.print( “M1 : ” ); t.start( ); System.out.print( “M2 : ” ); }}class WorkerProcess implements Runnable { public void run() { System.out.print( “Run ! ” ); }}Outputs: M1 : M2 : Run ! Outputs: M1 : Run ! M2 :Transactions - 10Originally prepared by: David Leberknight Thread SafetyInterleaved operations (by multiple Threads) can easily corrupt data. Whenever 2 or more concurrent Threads call methods on behalf of the same object, care must be taken to ensure the integrity of that object.For example, a JVM may switch Threads in the middle of a 64-bit long or double assignment :-( . 64 bit operations are not considered to be atomic. If some other Thread attempts to use the intermediate value of the half-copied double, something bad will likely happen. Thread BUGS can be hard to find and fix, especially in light of the following:The Java language does not guarantee Thread-switching fairness.Different JVMs use different Thread-switching algorithms, resulting in code that works on one platform but not on others.A single program may have different behavior on different runs.A program may crash one day after running correctly for long periods of time.Transactions - 11Originally prepared by: David Leberknight Thread Safety (cont.)Under what circumstances would this code not be “Thread-safe” ?!?public class Foo { private int maxElements = 10; private int numElements = 0; private Vector elements = new Vector(); public void add( Object newElement ) { numElements = elements.length(); if( numElements < maxElements ) { elements.addElement( newElement );} } }Two threads operating on one instance of this class at the same time; numElements = 9; both Threads get to point just before the if