exploiting semantics and speculation for improving the performance of read-only transactions

Exploiting Semantics and Speculation for Improving the Performance of Read-only

Transactions

T. Ragunathan and P. Krishna Reddy

International Institute of Information Technology (IIIT-H), Hyderabad.

E-mail: [email protected]

Outline• Introduction • Concurrency Control Protocols

• 2PL• SI-based Protocols• Speculative locking protocols• Speculative locking protocols for ROTs

• Proposed Concurrency Control Protocol for ROTs • Basic Idea: compensatability• Synchronous Speculative Locking for ROTs with Semantics

(SSLR-S)

• Simulation results• Conclusions and Future Work

Introduction• Modern information systems supported by DBMS

frequently receive read-only transactions (ROTs) or queries.

Issues for Processing ROTs• Performance

–High throughput performance • Correctness

– Serializability criteria

– Data Currency–Get the latest committed data

About Data Currency• Data currency

– “The data currency of the data object provided to Ti is the value of “t” which is the time difference between the commit time of the transaction which created the latest version of the data object and the commit time of the transaction which created the version of that data object that was read by Ti.

– If “t” is less/more, it means that transactions are provided with high/low data currency.”.

– Example: cricket score, stock value

Motivation

• Two-phase locking is a popular CC protocol – Performance of ROTs degrades with data

contention.

• Snapshot-isolation-based protocol is popular for ROTs– Suffers from data currency issues.– Correctness is compromised.

Motivation

• Speculative locking protocol (SL) – A transaction carries out multiple executions under

speculation

– Improves the performance by trading extra processing resources

• We are extending SL-based protocols to improve the performance of ROTs– 2PL is followed for UTs and SL is followed for ROTs – Issue: UTs are blocked in case of conflict with ROTs

Introduction

• We have proposed a protocol by exploiting semantics of ROTs for improving the performance. –Does not violate serializability criterias–No data currency related issues–Improves performance over other protocols.


• Two-phase locking• SI-based Protocols• Speculative locking protocols• Speculative locking protocols for ROTs


(SSLR-S)


Two-phase locking

• Popular concurrency control protocol. • Two phases

– Growing phase: transaction obtains locks– Shrinking phase: Transaction releases locks. It is not

allowed to obtain locks after releasing any lock.

Example under 2PL

nonoW

noyesR

WR

Lock Held by TjLock Request by Ti

T1 & T3 are UTs

T2 is a ROT

SI-based Protocols

• Transactions are processed at snapshot isolation (SI) level.

• An ROT reads data from the snapshot of the (committed) data available when it has started or generated the first read operation.

• An ROT running at SI is never blocked.

• SI-protocol with ``First Committer Wins Rule’’ – Let Ti and Tj be UTs. Ti will successfully commit if and

only if no concurrent Tj has already committed writes of data objects that Ti intends to write.

Example under SI-based protocol

• About SI-protocols• Ignores the effect of concurrent update transactions (UTs).– High performance– Data currency is compromised– Violates serializability criteria

T1 & T3 are UTs and T2 is a ROT

Example about Serializability violation under SI-based protocol

T1 & T2 are UTs T3 is a ROT

Speculative Locking Protocol

• Normally, a transaction starts producing after-images at the earlier stage of its execution.

• Though these after-image values are not effected during remaining processing, the transaction releases locks only after commit processing.

• In speculative approach, the transaction releases locks on a data object whenever it produces corresponding after-image value.

• By accessing both before- and after-images, the waiting transaction carries out speculative executions.

• A transaction commits only after receiving termination decisions of the preceding transactions.

Speculative Locking Protocol-Example

c2

T2:

r1[x0] w1[x1] r1[y0] w1[y1]

r2[x0] w2[x2] r2[z0] w2[z1]

r2[x1] w2[x3] r2[z0] w2[z1]

T1:

T21

T22

s1

s2

c1

c2

T2:

r1[x0] w1[x1] r1[y0] w1[y1]

r2[x0] w2[x2] r2[z0] w2[z1]

r2[x1] w2[x3] r2[z0] w2[z1]

T1:

T21

T22

s1

s2

c1

Once the after-image of `x’ is available, T2 can begin speculative executions. (until then it has to wait). But in 2PL, T2 has to wait until T1 commits. Thus, SL avoids waiting of transactions.

T2

r1[x0] w1[x1] r1[y0] w1[y1]

r2[x1] w2[x3] r2[z0] w2[z1]

T1

s1

s2 c2

c1

• SL

• 2PL

SL-Based Protocols for ROTs

• Straightforward extension of SL to process ROTs results into explosion of speculative executions.

• Because,–If we process UTs with SL, it leads to

explosion of speculative executions of ROTs and UTs.

–Number of data object versions in data object trees also explode.

Growth of Object trees

SL-based protocol for ROTSSL protocol

SL-based protocols for ROTs

• Processing:• UTs are processed with two-phase locking (2PL)

• ROTs are processed with speculation.

• Commitment:• ROTs commit whenever they complete.

• Method of carrying out speculative executions• Synchronous: Speculative executions of ROTs are carried out

synchronously

• Asynchronous: Speculative execution of ROTs ae processed asynchronously .

SL for ROTs : Example

Once the after-image of `x’ is available, T2 can begin speculative executions. (until then it has to wait). T2 can commit without waiting for T1.

T1 and T3 are UTs and T2 is ROT)

Lock Compatibility Matrix for SSLR

nono nonoEW

nono yesyesRU

sp_yes no yesyesRR

SPW EWRURR

Lock Held by Tj Lock Request by Ti

•We have used the following locks– RR - Read lock for ROTs– RU - Read lock for UTs– EW - Exclusive Write lock– SPW- Speculative Write lock

•`sp_yes’ indicates that the requesting transaction (ROT) carries out speculative executions by reading after-image of the data object. But,

this ROT can commit without waiting for preceding transaction.




(SSLR-S)


Basic Idea: Compensatability

• SL-based protocol for ROTs blocks UTs which conflict with ROTs.

• In the proposed protocol– UTs conflicting with ROTs are allowed to continue the

execution.– However, such ROTs have to perform compensating

computations during their commitment • The property of ROTs which allow compensation, is

called “compensatability”.• The compensatable ROTs need not perform

speculative executions.

Compensatability: An Example

• T1 is an ROT and T2 is a UT. Both are concurrent transactions.

• T1: r[x], r[y], z = x + y, d[z], commit.

T2: r[y], y = y+10, w[y′], commit.

• While T1 performs the computation (z = x + y), T2 modified the ‘y’ value to ‘y+10’ (‘y′’)

• The computation performed by T1 (addition) satisfies the “compensatability” property.

• Here the compensating function (g) for T1– “z + (y′ – y)”.

Formal definition: Compensatability

• Let Ti be an ROT and Tj be a UT.

• Consider that Ti accesses data object ‘x’ at the time instant ‘ts’ and produces new data object ‘y’ at the time instant te (te > ts).

• In parallel, Tj accesses ‘x’ and produces ‘x′’ at time instant tu (ts < tu < te).

• Here ‘x′’ is the value of ‘x’ modified by Tj . Consider that if Ti would have accessed ‘x′’, it would have produced new data object ‘z’.

• We say, the computation by Ti on ‘x’ is “compensatable”, if there exists a function or computation ‘g’ such that z=g(x′).

Overview of the proposed protocol • Based on the compensatability property of ROTs, the

ROTs are classified into – Compensatable ROTs (CROTs) and – Non-compensatable ROTs (NCROTs)

• CROTs are executed without blocking and NCROTs are executed with speculation (SSLR).

• CROTs perform compensating computations once they are completed.

• UTs in compatible with CROTs alone are processed without blocking.

Compensating Operations for CROTs

• Whenever a CROT conflicts with UT the IDs of data objects which have been modified by that UT are recorded by the CROT.

• After its completion, a CROT searches for the IDs of data objects in the transaction log.

• The CROT performs the compensating computations as per the procedure available in the transaction program of that CROT.

Transaction Processing with SSLR-S

T1 is ROT, T2 is UT

Lock compatibility matrix for SSLR-S

CR lock – Compensatable Read lock

NR lock- Non-compensatable Read lock




(SSLR-S)


Simulation Model

• Discrete event simulator based on a closed-queuing model is developed.

Simulation Parameters

• Discrete event simulator based on a closed-queuing model is developed.

Performance Metrics

• Throughput

# of transactions, ROTs, UTs completed per second

• Average number of speculative executions per transaction.– Let ‘e’ be the number of speculative executions performed

and ‘n’ be the number of transactions executed in the system.

– Average number of speculative executions per transaction = e/n

% of CROTs versus Throughput (30% UTs)

% of CROTs versus Throughput (50% UTs)

% CROTs versus UTs Throughput ( 30% UTs)

% CROTs versus UT Throughput (50% UTs)

% CROTs versus ROT Throughput ( 30% UTs)

% of CROTs versus ROT Throughput (50% UTs)

% of CROTs versus Average number of speculative executions ( 30% UTs)

% of CROTs versus Average number of speculative executions ( 50% UTs)

• “% of UTs” (u) denotes percentage of UTs currently active in the system.

• “% of CROTs” (c) means percentage of CROTs active in the system.

• “% of NCROTs” active in the system

= (100 - u – c)




(SSLR-S)

• Simulation Results• Conclusions and Future Work

Conclusions and future work

• Proposed an improved protocol for ROTs by exploiting the notion called “Compensatability” of ROTs and speculation.

• Improves the performance of ROTs over 2PL, Snapshot Isolation and SSLR protocols.

• Requires less number of speculative executions than SL protocol.

Conclusions and future work

• Future work –Investigate more about how an ROT can be

made compensatable by considering TPC benchmarks

–Investigate the performance by applying the proposed protocol in data warehousing environment.

Thank you

Related Work• Four isolation levels are specified in ANSI/ISO

SQL-92 standard –read uncommitted, read committed, repeatable

read, and serializable.Satya Narayanan and Agrawal (1993). • Multiversion environment. ROTs are processed

separately. The problem with this approach is delayed visibility. For example, an ROT executed immediately after a UT ‘Ti’ may not see the results of ‘Ti’ (Data currency problem).

Related Work

• To get high currency, the ROTs have to be executed as pseudo-update transactions. So, the performance will be reduced.

Mohan et.al. 1992• Multiple versions of data objects are maintained, Also,

a version of a data object is valid for a particular interval (version period).

• The ROTs are allowed to access a particular version of the data object, based on their arrival time.

• Any modification performed on that data object is visible only in the next version period. So ROTs are provided with low data currency.

Related Work - SI

• Snapshot Isolation–Serializability Violation–Low Data Currency Problem

• Recently Alan Fekete (ACM June 2005) has made an effort to make SI serializable. They suggested a theory using which static dependencies between transaction programs have to be identified. Then a SDG (Static dependency graph) has to be formed. In this SDG each node is a transaction program.

Related Work - SI

• From the SDG, vulnerable edges have to be identified. If vulnerable edges form a cycle, pivot element is identified.

• The program representing the pivot element has to be run in 2PL mode in order to avoid anomalies.

• Materializing conflict (adding new tables and adding entries by the transaction programs. This may increase the aborts due to FCWR) and Promotion (modifying the program code) are other techniques to avoid anomalies.

Related Work - SI

Sudhir and Fekete (VLDB 2007) • They are working on a tool to analyze the SQL

transaction statements to identify the “pivot” programs which may cause anomalies (VLDB 2007). This tool requires description on tables and SQL transaction statements collected from the log or trace. The tool cannot directly work on the transaction code.

• But, to avoid anomalies, still the DBA has to manually perform one of the three techniques (Running with 2PL, Materializing conflict or Promotion).

Related Work-Speculation

• Speculation has been extended in (Bestvaros and Braoudakis, 1995) to optimistic protocol for improving the deadline performance in centralized real-time environments.

• Speculation has been extended to improve the performance of distributed database systems.

Related Work- semantic-based approach

• (Gray, J. N , 1981) briefly presents the use of commutative property of arithmetic operations plus and minus, to reduce the lock contention for data objects.

• (Hector Garcia-Molina, 1983) how commutative steps of distributed transactions can be interleaved to improve the performance is discussed.


• (Akhil Kumar, Michael Stonebraker, 1988) – proposed multi-copy algorithm for replicated environment

which exploit the application semantics. – classify the transactions as C type and NC type based on

commutativity – a property called mc-commutativity which is defined based

on C and NC type. – formalize the conditions under which these types of

transactions can execute independently in parallel at different sites.

– claim that it is suitable for retrieval and update environments where data is replicated.


• Muth., P and others, 1993.– Proposed a locking protocol for object databases which uses method

commutativity.

• Badrinath., B. R., and Ramamritham, 1992.– Identified “ recoverability” which can be used to decrease the delay involved

in processing non-commuting operations while still avoiding cascading aborts.

• Paul Wu and Alan Fekete, 2008.– Experimental study performed on an application used in telecom sector.– Shows the potential in real-world applications for improving the performance

through semantic-based approaches.

Lock Compatibility Matrix

sp_yesnosp_yesEW

sp_yesnoyesR

SPWEWR

Lock Held by TjLock Request by Ti

• W-lock is divided into two parts : EW (exclusive write)-lock, SPW (speculative write)-lock

• EW-lock on a data object is converted into SPW-lock, once the after-image of the data object becomes available.

•`sp_yes’ indicates that the requesting transaction carries out speculative executions and forms commit dependency with the preceding transactions that hold SPW-locks.

exploiting semantics and speculation for improving the performance of read-only transactions

Documents