A New Method for Concurrency Control in Centralized Database

Systems 

Victor T.S. Shi and William PerrizoComputer Science, North Dakota State University

Fargo, ND 58105, USA

(Patents are pending on the ROCC technology describe herein)

The Problem

Scale-up: Buying a bigger and faster machine (2X TPS)

Replication: Placing data at two machines and keep the data current

100 users

100 users

100 users

Base case:a 1X TPS system

1X TPS server

2X TPS server

1X TPS server

1X TPS server

100 users

100 users

2X TPS server

2X TPS server

Partitioning:dividing the work between two machines

Doubling the number of users increases total workload by a factor of four, causing an 8 fold increase of deadlocks (2PL) or restarts (OCC). J. Gray, P. Helland, P. O’Neil, D. Shasha, “Danger of replication and a solution”, ACM SIGMOD, 1996, pp.173-182.

Our Experimental Platform

Switch

DB node 1

2

N

Local distributed database system

16 PC boxes providing 64 ×16=1024 GB data storage, connected by a gigabit switch (WUGS).

Problems to Solve

Expected situation: High system throughput, short and predictable transaction response time.

Traditional method used in most commercial products for concurrency control is two phase locking. It no longer can be assumed optimal for a high performance system due to potential thrashing behavior and problems in distributed environments with uncertain network latency.

[1] R. Agrawal, M. Carey and M Livny, “Concurrency control performance modeling: alternatives and implications”, ACM Transaction On Database system, Vol.12, No.4, 1987, pp. 609-654.

[4] P. Franaszek, J. Robinson and A. Thomasian, “Concurrency control for high performance environments”, ACM Transactions on Database Systems, Vol. 17, No.2, 1992, pp.304-345.

Our Solution: Read-commit Order Concurrency Control (ROCC)

A transaction may send multiple access request messages, each one containing one or more access operations.

The switch “intercepts” the request messages as they flow through it.

When a new request message arrives, an “element” will be generated containing the identifier of the transaction and the data items to be accessed.

The element is posted to a Read-Commit queue (RCqueue) maintained in the switch.

When a commit request arrives, the switch will perform validation based on the RC queue, to decide whether or not the transaction can commit.

Database sites access the requested data items based on FCFS (first come first served) discipline.

Writes are delayed to avoid cascading abort.

ROCC: Procedures

Switch

DB node 1

2

N

Local distributed database system

SPC

Client-side procedure

Client-side procedure

Active-Networking-switch-side procedure

Active-Networking-switch-side procedure

Database-side procedure

Database-side procedure

Techniques Used in ROCC

We use an OCC mechanism, thus a restart-based approach (no deadlocks).

We limit restarts of a transaction with pessimistic “ over-declaration” after n restarts (no livelock).

Bit-vector-oriented hardware validation (bit vector table) relieves the CPU burden.

Writes are delayed (organized into one commit element) to reduce the chances of validation failure (writes have higher probability of conflict with other operations).

If all intervening elements are Read elements, no validation is needed. (since writes are delayed, there is no chance of two or more elements conflicting)

Read-Commit Queue (RC queue)

Tid V C R R/W Next

The element format:

T1 0 1 0 Writes Next

T3 1 1 0 Reads Next

T1 0 0 0 Reads Next

T0 0 0 0 Reads Next

T2 1 0 1 Reads/Writes Next

NULLExample of RC

Transaction ID

Validated

Commit

Restart Read/Write

Read element Commit elementRestart element Validated element

RC Element Definitions

Read elementRepresents the request message a transaction submits, contains the identifiers of data items it requests to read. All the write requests are delayed until commit; thus they only appear in Commit elements

Read elementRepresents the request message a transaction submits, contains the identifiers of data items it requests to read. All the write requests are delayed until commit; thus they only appear in Commit elements

Commit elementRepresents a commit request message of the corresponding transaction. It contains all the identifiers of data items that the transaction requests to write.

Commit elementRepresents a commit request message of the corresponding transaction. It contains all the identifiers of data items that the transaction requests to write.

Restart elementThe active switch generates a Restart element when the validation of a transaction fails. The Restart element contains all the identifiers of data items that the failed transaction intends to read and write

Restart elementThe active switch generates a Restart element when the validation of a transaction fails. The Restart element contains all the identifiers of data items that the failed transaction intends to read and write

Validated elementThe Validated element corresponds to transaction that has validated, or transaction that doesn’t need validation (static or restarted transaction)

Validated elementThe Validated element corresponds to transaction that has validated, or transaction that doesn’t need validation (static or restarted transaction)

Functional Specification of SPC

Dispatcher

VP0

Receive Queue

Transmit Queue

RC0 RC1 RCn

RCQueue

VP1 VPn

From clients

To database servers

Smart Port Card

Smart Port Card: Active Processing Unit

port 2

port 1Experimental FPGA

MainMemory

Cache CPU

Intel Embedded Module

SystemFPGA APIC

PCI Bus

The Features of ROCC

High system throughput (due to optimistic nature)

Short, predictable and controllable transaction response time (desired feature in real time systems)

Reduced restarts (a transaction restarts only when two or more elements conflict with intervening elements)

Reduced validation complexity (no validations needed for static and pessimistic restarted transactions – only intervening conflict checked).

Fast hardware-level validation (bit vector oriented hardware design).

Deadlock and Livelock free.

The Features of ROCC

Developed ROCC due to dramatic increase of deadlocks in 2PL and repeated restarts in OCC (J. Gray, P. Helland, P. O’Neil, D. Shasha, “The danger of replication and a solution”, proceedings of the ACM SIGMOD conference, 1996, pp.173-182.)

ROCC takes the advantages of physical star or tree topology of our LAN and active processing concepts for performance improvements, though the star or tree topology is not necessary.

The SPC cards and the WUGS switch provide a nice environment to test ROCC in a combination of software and hardware levels.

ROCC Homepage: http://midas.cs.ndsu.nodak.edu/~dyu/

• Contains simulation results which can be verified with the software on this page (simulator can be downloaded).

The Performance of ROCC

We compared ROCC with 2PL, OCC and WDL (Wait Depth Limit).

The simulation results are shown in next slides. The parameter settings are as follows.

We assume a client may send multiple access requests to the data server.

The average intra-transaction think time is 1 second.

The database size is 1000 pages.

The Transaction size varies:4-6 pages for low data contention environments10-16 pages for high data contention environments.

Disk I/O is 35ms and CPU processing time per page is 10ms.

The transaction throughput shown is defined as the number of transactions completed per second.

The restart ratio is defined as the average number of times a transaction restarts per commit.

2PL was run just enough to determine the thrashing point (very long simulation times required)

ROCC Throughput (transaction size=4-6 pages accessed – low contention)

ROCC Throughput (transaction size=10-16 pages accessed – high contention)

ROCC: Restarts (transaction size=4-6 pages accessed)

ROCC: Restarts (transaction size 10-16 pages accessed)