A New Method for Concurrency
Control in Centralized Database
Systems
Victor T.S. Shi and William Perrizo
Computer Science, North Dakota State University
Fargo, ND 58105, USA
(Patents are pending on the ROCC technology describe herein)
The Problem
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.
Base case:
a 1X TPS
system
100 users
Scale-up: Buying
a bigger and
faster machine
(2X TPS)
100 users
1X TPS server
2X TPS server
100 users
100 users
1X TPS server
100 users
1X TPS server
Partitioning:
dividing the
work
between two
machines
2X TPS server
2X TPS server
Replication:
Placing data
at two
machines
and keep the
data current
Our Experimental Platform
Local distributed database system
DB node 1
2
Switch
N
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.304345.
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
Client-side
procedure
Active-Networking-switch-side
procedure
Database-side
procedure
Local distributed database system
SPC
DB node 1
2
Switch
N
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)
Read element
Restart element
Commit element
Validated element
NULL
Example of RC
T0
0
0
0
Reads
Next
T1
0
0
0
Reads
Next
T3
1
0
Reads
Next
Writes
Next
The element format:
Transaction ID
Commit
Tid V
C
R
Validated Restart
R/W
1
Next
Read/Write
T1
0
1
0
T2
1
0
1
Reads/Writes Next
RC Element Definitions
Read element
Restart element
Represents 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
The 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
Commit element
Validated element
Represents a commit request
message of the corresponding
transaction. It contains all the
identifiers of data items that the
transaction requests to write.
The Validated element
corresponds to transaction that
has validated, or transaction
that doesn’t need validation
(static or restarted transaction)
Functional Specification of SPC
Smart Port Card
Receive
Queue
From
clients
RC
Queue
Transmit
Queue
To
database
servers
Dispatcher
VP0
VP1
VPn
RC0
RC1
RCn
Smart Port Card: Active Processing Unit
Cache
CPU
Intel Embedded Module
Main
Memory
PCI Bus
Experimental
FPGA
System
FPGA
port 1
APIC
port 2
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 environments
10-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)