Performance Evaluation of Speculative Locking with unlimited resources M.Tech Presentation by G. Uday Kiran Reddy

Contents Introduction Speculative Locking & Performance Evaluation Simulation Model Results & Conclusion

Contents IntroductionIntroduction Speculative Locking Simulation Model & Performance Evaluation Results & Conclusion

Introduction Database: a fixed set of named resources (eg, tuples, data items, pages, files, …) Consistency Constrains: must be true for DB to be considered “consistent”. For example each employee has a valid department bal – amount > 500 sum(account balances) = sum(assets)

Introduction Transaction: a sequence of actions with begin and end statements. Each transaction is assumed to maintain consistency. (system should guaranty this) begin … … … read i (X); write i (X); … … … end; Main goal is Concurrent execution of many transactions with high throughput, low response time.

Introduction ACID test for transaction management Atomicity: either all actions within a transaction occur, or none do. Consistency: each transaction takes the database from one consistent state to another. Isolation: events within a transaction must be invisible to other transactions. Durability: once a transaction is committed, its results must be preserved even in the case of failures.

Introduction So, we should allow many transactions to execute concurrently. Arbitrary interleaving can lead to: - temporary inconsistencies. - “permanent” inconsistencies. We face many problems like: - Lost Update problem - Dirty read problem - Incorrect summary problem

Introduction Concurrency Control - Locking It’s a technique to ensure serializability and preserve high concurrency as well. A “lock manager” records what entities are locked, by whom, and in what “mode”. It also maintains wait queues. A well formed transaction locks entities before using them, and unlocks them some time later.

Introduction Two Phase Locking Growing phase: A transaction may obtain locks but not release any lock Shrinking phase: A transaction may release lock, but not obtain any new lock.

Contents Introduction Speculative LockingSpeculative Locking Simulation Model & Performance Evaluation Results & Conclusion

Speculative Locking In two-phase locking(2PL) A transaction obtains locks during the execution and releases them only after the completion of the commit processing. In speculative locking A transaction releases the lock on the data object whenever it produces corresponding after-images during its execution.

Speculative Locking ExecutionCommit sisi eiei c i /a i r 1 [X] w 1 [X’] r 1 [Y] w 1 [Y’] r 2 [X] w 2 [X’] r 2 [Z] w 2 [Z’] s1s1 e1e1 c1c1 s2s2 e2e2 c2c2 r 1 [X] w 1 [X’] r 1 [Y] w 1 [Y’] s1s1 e1e1 c1c1 r 2 [X] w 2 [X’’] r 2 [Z] w 2 [Z’] r 2 [X’] w 2 [X’’’] r 2 [Z] w 2 [Z’’] T1T1 T2T2 T1T1 T2T2 T 21 T 22 s2s2 e2e2 c2c2 TiTi Processing of T i Processing with 2PL Processing with SL

Speculative Locking Lock requested By T i Lock held by T j RW Ryesno W Lock requested By T i Lock held by T j REWSPW Ryesnosp-yes EWsp-yesnosp-yes Lock compatibility matrix – 2PL Lock compatibility matrix – SL

Speculative Locking Commit dependency rules: T i forms a commit dependency with T j 1.T j is already holding either R-lock or SPW-lock and then T i obtains the EW-lock 2.T j is already holding an SPW-lock on the data object and T i obtains the R-lock. * At any time, only one transaction holds an EW-lock on the data object

Contents Introduction Speculative Locking Simulation Model & Performance EvaluationSimulation Model & Performance Evaluation Results & Conclusion

Simulation Model Distributed descrete event simulation model is developed. Communication network is modeled as fully-connected network. ‘sim_clock’ simulates the real time clock(not the system clock).

Simulation Model

Pseudo code of the main simulation model while(all transactions are not completed) { generate transaction;/* by Trans_Generator */ generate initial events for the transaction; position them in event_queue min-heap; while(event_queue min-heap is not empty) { get min timed-event from the event_queue; update the simulation_clock accordingly; service the event /* this may generate some more future events */ }

Messaging in the Simulation Messages are used extensively to communicate between sites in our simulation model. Message Type Arrival Time Sender Receiver Transaction_Id Data Object Status Flags & other related info Structure of the Message

Types of Messages new_transaction: When a transaction arrives at site Sk the Trans_Generator itself generates this new_transaction event. lock_request: This message is sent by a transaction to site Sk to get a lock on data item X which resides at site Sk. lock_reply: This is a reply to lock_request message when the lock is available. send_Xai:This message is sent by the transaction whenever it produces after-images in the transaction. prepare: On completion of transaction Ti’s execution, this PREPARE message is sent by the coordinator to participants. vote_commit: participants sends VOTE_COMMIT mesg to coordinator when they are ready to commit.

Types of Messages vote_abort: participants sends VOTE_ABORT mesg to the coordinator when they are aborting the transaction global_commit: when coordinator receives all vote_commit messages from all participants, this mesg is sent to all participants global_abort: when coordinator receives at least one vote_abort mesg from any participants, this mesg is sent to all the participants.

Message Communication in the Simulation

Simulation Parameters Database Size: is the number of data objects (data items, e.g. tuples, records or number of pages) in the database. Every data object has an equal probability of being accessed and a random function is used to determine which objects would be accessed by each transaction. Concurrency Level: is the number of transactions executing at any moment in the database (including those blocked). The concurrency level values were varied between 10 to 50 transactions. Transaction Size: is the average number of data objects requested by the transaction. It is computed as the mean of a uniform distribution between max_size and min_size (inclusive). Write Probability: refers to the probability that an object read by a transaction will also be written. The probability that we used is 1. That means, we are assuming every object is read before they write.

Simulation Parameters Local-to-Global ratio: is the ratio of the number of local requests to the number of total requests for a transaction. In our simulation, we fixed this value to Transmission time: is the time taken to transfer a message from one site to the other site in Distributed Database Systems(DDBS). Varying the value of the transmission time enables a study of the effect of the network model(LAN or WAN) on the performance of the algorithm. CPU and I/O time: The time required to carry out a CPU request is CPU-TIME and the time required to carry out an I/O request is IO-TIME. We have fixed these values CPU-TIME as 15 msec and IO-TIME as 30 msec.

Simulation Algorithms new_transaction event /* initialize settings for transaction */ list[index].depend_set_Ti[0] = 0; list[index].executions = 1; depend_abort[index] = 0; for( i = 1 to list[index].num_of_items) { add new event of type lock_request for the data item list[index].objects[i]; }

Simulation Algorithms lock_request event update site_clock; if (queue for data_item is empty) { grant the lock; send lock_reply message to HSi; } else if(previous transaction is in Waiting) { push LRik(X) into the data_item's queue; }

Simulation Algorithms else if(previous transaction is in Notwaiting and holding SPW lock) { grant EW lock; /* since Ti forms commit-dependency with Tj); update depend_set(LR); send lock_reply mesg along with X's tree and depend_set(LR); } else if(previous transaction is in Notwaiting and holding EW lock) { push LR(X) into the queue of X; } lock_request event

Simulation Algorithms lock_reply event update site_clock; note down that lock is granted for one of the objects; for each Tis (s=1.. m) for each Xq (q=1... v) { Tis branches to new execution Tit with Xq; update depend_set(Tit); } m = t; update depend_set(Ti);

Simulation Algorithms lock_reply event /* Assume Ti issues Wi[X} operation */ for each Tis { /* Xp is after-image of X produced by Tis */ depend_set(Xp) = {depend_set(Tis)} U {Ti}; send Send_Xai message along with Xp's and their depend_sets; } if( all locks are completed) { /* start 2PC */ send PREPARE message to each participant; }

Simulation Algorithm send_Xai event update site_clock; include each after-image as a child to the corresponding before-image; convert EW-lock on X to SPW-lock type; /* since Ti is now holding SPW-lock on data_item X */ grant EW-lock to waiting transaction Tj on data_item X; if(Tj forms commit-dependecy with Ti) { update depend_set(LR); } /* Tj is waiting on X */ send lock_reply mesg to HSj of Tj;

Simulation Algorithm prepare event update site_clock; note down that this site Sk received prepare mesg form Coordinator; for all X belongs to access_set of Ti at Sk if(depend_set(LRik(X)) is null) { send VOTE_COMMIT mesg to Coordinator; }

Simulation Algorithms vote_commit event update site_clock; note down that VOTE_COMMIT mesg is received from one of participants; if(Coordinator received VOTE_COMMIT mesg from all participants) { send GLOBAL_COMMIT mesg to al participants along with after-image; }

Simulation Algorithms global_commit event update site_clock; /* Xp is received from Coordinator */ replace X's tree with subtree being Xp as the root. for all w { delete Ti from depend_set(Tw); for( s = 1 to u) if(Ti does not belong to depend_set(Tws)) drop Tws; }

Simulation Algorithm global_commit event /* since Tw is accessing X which was accessed by Ti */ for all w delete Ti from depend_set(LRwk(X)); if( all global_commit mesg are processed) { delete transaction from list data structure; remove transaction from memory; }

Contents Introduction Speculative Locking Simulation Model & Performance Evaluation Results & ConclusionResults & Conclusion

Results

Thank you !!!