DATABASE CONCURRENCY CONTROL USING TRANSACTIONAL MEMORY :
PERFORMANCE EVALUATION
Jeong-Seung Yu
†‡a, Woon-Hak Kang
†b, Hwan-Soo Han
†cand Sang-Won Lee
†d†School of Info. & Comm. Engr. Sungkyunkwan University Suwon 440-746, Korea ‡Altibase Corp. 182-13, Guro-dong, Guro-Gu Seoul, 152-847, Korea
{a
tinyisle,
bwoonagi319,
chhan,
dswlee
}@skku.edu
ABSTRACT
Recently, multi core processors are widely used. In multi
core environment, programs should be parallelized to maxi-mize utilization of the processor. In parallel programming, locking method has been used for concurrency control. And most of current database systems also use locking method. Concurrency control scheme based on locking method has not been parallelized due to a locking overhead. It is one of the most obstacles to system performance in multi core en-vironment. Transactional memory has been proposed as an alternative. It provides lower overhead and more parallelism than locking method. In this paper, we evaluate the per-formance of concurrency control schemes using transactional memory, optimistic concurrency control and locking method
respectively. Our experimental results show that
transac-tional memory is up to 9 times faster than the others and it is more effective in OLTP environment which mainly has short and read-intensive transactions.
K ey w ords— Database, Concurrency Control,
Opti-mistic Concurrency Control, Transactional Memory, Multi-core
1.
INTRODUCTION
In the past, processor development focused on finding a sin-glecore processor which had faster speed and higher clock. However, recent movement of processor development is not making a singlecore processor, but is changed to make a mul-ticore processor which contains many cores on one chip. This movement promotes the change of software development. In-creasing clock speed has resulted in higher speed of
appli-cation programs so far. But application programs cannot
get ‘free lunch’ anymore as processor development focuses on making much more cores rather than clock speed. In multi-core environment, application programs have to be designed to utilize parallelism efficiently. Previous sequence programs cannot use cores in a multi core processor, and it results in decreased total throughput.
Assume the case when several threads access to shared resource in parallel programs. Indiscreet access to shared re-source without control method can cause incorrect outcome. Traditionally, locking method such as mutex and semaphore
is used as a solution to prevent this problem. In locking
method, shared resource can be accessed only if thread has a lock. Otherwise it is impossible to access to shared resource and it is necessary to wait until getting a lock. Moreover,
each access to shared resource gets a lock, and overhead to maintain is very heavy in locking method. These properties make processor utilization less effective.
Transactional memory was introduced to solve these weak points of locking method. Transactional memory is concur-rency control method that guarantees atomic execution for operation sequence called transaction. Transactional memory does not have overhead which locking method has in order to get and manage lock. If simultaneous accesses for shard memory do not cause any problems, first, overhead caused by a lock is waste. Also, Transactional memory which does not have this overhead caused by a lock has better performance than locking method.
For better process, database system also allows many transactions to access to shared data at once. Furthermore, locking method has been traditionally used as concurrency control method to control transactions which access simulta-neously. Overhead caused by a lock is main reason for de-creasing system performance in programs, such as database system, which has many parallel accesses to shared data.
In parallel programming field, concurrency control in database system can be implemented by using transactional memory which is suggested to overcome locking method. This can improve processor utilization in multicore environment. The paper is organized as follows. Section 2 deals with lock-ing method, optimistic concurrency control in database, and transactional memory in parallel programming. Section 3 dis-cusses optimistic concurrency control implementation using transactional memory. Finally, Section 4 contains conclusion and future research.
2.
BACKGROUND
This section explains typical concurrency control methods of
database and parallel programming. Locking method and
optimistic concurrency control in database systems will be explained first and then transactional memory in parallel pro-gramming will be the next.
2.1
Locking method
Locking method is the most popular concurrency control method in data base system. In locking method, all transactions have to get an appropriate lock before accessing shared data. If not, transactions have to wait until getting a lock. Lock is separated into two classes, shard for reading and exclusive
lock reading and writing. Shared lock can be gotten with the shared lock which is held by other transactions at once, on the other hand, exclusive lock can be only gotten by one transaction at a time.
Locking method has several weak points. First, it is lock management overhead. Not only the overhead searching a node to get a lock but also other overhead, such as holding, converting, and releasing a lock, are big. Another problem is lock waiting overhead when requested lock is not compat-ible. Waiting to get a lock has negative effects on overall throughput and response time. The most serious problem is deadlock. Deadlock occurs when one transaction holding a lock waits for another lock held by another transaction. For example, if transaction A waits for a lock held by transaction B, and transaction B waits for a lock held by transaction A, both transactions cannot proceed. Both ones will keep wait-ing unlimitedly. To solve this problem, one transaction has to be aborted and all locks hold by that transaction has to be released. If many transactions run simultaneously, these problems become more serious.
2.2
Optimistic Concurrency Control
Another concurrency control method in database field is Op-timistic Concurrency Control [1]. It was introduced to supple-ment the week points of locking method. In locking method, the basic premise is that transactions running concurrently cause problems with consistency. Therefore, lock is used to prevent problems. In optimistic concurrency control, on con-trast, the basic premise is that transactions running concur-rently do not cause consistency problems in most cases. As consistency problems do not occur, the lock which causes
overhead is not necessary. Optimistic concurrency control
does not have overhead for lock management and deadlock because it does not use any lock.
In optimistic concurrency control, transactions proceed in three phases; read, validation, and write phase. In read phase, the transaction executes all operations. Information on data set which transaction creates, deletes, reads, and writes is kept. In addition, created or updated operation out-comes are kept in a local area only for certain transaction. In validation phase, the transaction performs a validation test to see whether consistency problems occur or not. If transaction succeeds in validation, it performs write phase. If transaction fails in validation, transaction is aborted and restarted. In write phase, new values which are kept in a local area are spread to a global area. It means new values are global data, so other transactions can access to them.
Optimistic concurrency control has better overall through-put and response time than locking method because it does not have overhead by using a lock. However, it has some disadvantages as well. First, while it does not have
dead-lock, it has starvation problem. When one transaction is
aborted continually by another transaction, it is called star-vation. It can causes bad response time. In this situation, one transaction which conflicts with the other transaction needs to be temporarily blocked so that the other transaction can be finished. Another problem is that performance depends on transaction length and write operation rate. Because the transaction which has short running time or is read intensive has lower possibility to conflict, it works well. The opposite
is also true. The transaction which has long running time or many writing operation has more chance to conflict does not work well with many returning and restarting.
2.3
Transactional Memory
In parallel programming field, as well as database system, if several threads access to the same shared memory, the syn-chronization scheme is needed. In most cases, locking method such as mutex and semaphore is widely used, like database system. Locking method in parallel programming has prob-lems with deadlock or managing and waiting for a lock like locking method in database system.
Another problem with locking method is that it is diffi-cult to design, debug, and maintain program. The more locks are used, the more this overhead is increased.
Transactional memory was introduced by Lomet [2] in order to avoid overhead caused by using a lock. It was first implemented by Herlihy and Moss [3]. Transaction memory came from the concept of transaction in database. Transac-tional Memory ensures atomicity and isolation among four properties of database transaction; atomicity, consistency, isolation, durability. Atomicity makes sure overall state changes of operations in a transaction. In other words, overall opera-tions of a transaction appropriately finish being executed or not at all. Isolation means even if several transactions are executed concurrently, operation result of each transaction cannot affect another transaction operation.
If confliction occurs between transactions which have dif-ferent result from each other, transactional memory aborts execution results and restart to ensure atomicity. By ensur-ing that result of transaction executions is invisible to an-other transactions before it is completed, transactional
mem-ory guarantees isolation. This property is very similar to
optimistic concurrency control in the database.
Transactional memory is separated into hardware trans-actional memory [3, 4, 5, 6] and software transtrans-actional mem-ory [7, 8, 9] based on its execution. Hardware transactional memory cannot apply to a transaction which exceeds cache size because transaction keeps the information about accessed data into processor cache. However, it has better performance
than software transactional memory. Conversely, software
transactional memory is slower than hardware transactional memory, but it is independent of hardware.
Version Management Lazy Eager Conflict Lazy OCC DBMSs[1] none Stanford TCC[5] Eager MIT LTM[4] CCC DBMSs[10]
Intel/Brown VTM[6] MIT UTM[4]
(on cache conflicts) LogTM[11]
Table 1: A Transactional Memory (TM) taxonomy
Table 1 illustrates which transactional memory propos-als use lazy versus eager management and conflict detection. Eager confliction detection is when confliction detection is ex-ecuted at the point of read or write operation. If confliction detection is executed later, not at read or write operation but
complete point, it is lazy one. Eager version management is when new values are stored in place directly. If new values are stored in some place temporarily and then stored again in a right place later, it is lazy one.
3.
CONCURRENCY CONTROL
IMPLEMENTATION USING
TRANSACTIONAL MEMORY
Transactional memory is essentially similar to optimistic con-currency control. Both methods hope that most parallel ac-cesses do not make any problems. Moreover, both methods do not prevent conflict before accessing to such as locking method, but both detect and handle conflict after access-ing. These similarities provide the possibility to develop opti-mistic concurrency control in database system by using trans-actional memory. We can use transtrans-actional memory as a sub-stitute for version management and conflict detection func-tion in optimistic concurrency control. Furthermore, trans-actional memory has strong points of performance as well as convenience of program development. As previously men-tioned, transactional memory can help to make the best use of multi core than locking method. Therefore, optimistic con-currency control using transactional memory can make better performance than locking method.
3.1
Evaluation Setup
The computer used in the experiments has Intel i5-760 2.8GHz Quad-Core processor and 4GB ram. That processor has four cores and support hyper-threading.
We assume that the database in our experiments is OLTP database which is accessed by many transactions concurrently. Each record is 64byte, and one page consists of 64 records. The entire database consists of a single table which has 25,000 pages, and all data are main memory database management system stored in main memory. We ran 500 threads concur-rently with 25,000 transactions which executes read or write operation to accessed records.
In the experiments, Intel C++ Compiler Prototype Edi-tion 3.0 [12], which is one of the software transacEdi-tional mem-ory, is used. Although it is slower than hardware transac-tional memory, it supports transactransac-tional memory with com-piler level and does not have hardware limit. It identifies codes defined as the keyword, “ tm atomic” and ensures atomic execution by tracking a conflict in 64byte memory address.
We use optimistic concurrency control method introduced by H.T Kung and Jone T. Robinson. However, consider only read and write operation.
In locking method, we use a record-level locking and two locking modes, such as shared lock and exclusive lock. The records which will be accessed by transaction are sorted based on the record identifier order in advance. When transactions access to a record, transactions acquire a lock in order from low record id to high record id and release a lock in reverse order.
3.2
Performance on Singlecore
For single core environment, only one core among four cores is enabled. Each transaction executes read or write op-eration for 10 records and each opop-eration reads or writes a data which is 1 word size. The records to be accessed are selected randomly in the entire database.
0 10 20 30 40 50 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%)
Transactional Memory Optimistic Concurrency Control Locking Method
Figure 1: Execution time for short transactions
Figure 1 shows the performance of each concurrency con-trol in single core. X-axis is the rate of read operation among 10 times access to record, and Y-axis is execution time. All concurrency control methods show similar execution time for the case of read operation only and write operation only. Locking method takes approximately 45 seconds for read op-eration only. It means locking method has huge overhead for lock management Transaction memory and optimistic con-currency control are much faster than locking method. The reason is that transactional memory and optimistic concur-rency control are strong in short transactions.
Figure 2(a), 2(b), and 2(c) show the result of the perfor-mance when the number of record accessed by transactions is changed. If the number is increased, transaction operations which make execution time increased are increased. Figure 2(a) and 2(b) show that execution time for both transactional memory and optimistic concurrency control will be increased as the number of record rises. Figure 2(c) shows that, how-ever, there will not be big change of execution time in locking method even if the number of record rises. It shows overhead caused by lock management is much heavier than overhead caused by read or write operations in locking method.
We executed each method under heavier computation condition. In this case, one write operation executes com-putations 64 times. Figure 3 shows the result of the perfor-mance of both transactional memory and optimistic concur-rency control when each transaction accesses to 50 records. Execution time of both is increased more than the past periment. The reason is that increased execution time by ex-ecuting 64-time computations causes more conflict between transactions. In locking method, the result is similar to figure 2(c). It means that lock management time has more effects on the entire performance than computation time.
0 0.1 0.2 0.3 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) TM 50 Records
TM 30 Records TM 10 Records
(a) Transactional Memory
0 0.1 0.2 0.3 0.4 0.5 0.6 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) OCC 50 Records
OCC 30 Records OCC 10 Records
(b) Optimistic Concurrency Control
45 46 47 48 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) Lock 50 Records
Lock 30 Records Lock 10 Records
(c) Locking Method
Figure 2: Execution time on various transaction length 0 1 2 3 4 5 6 7 8 9 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) Transactional Memory
OCC
Figure 3: Execution time on heavy computation
3.3
Performance on Multicore
The number of core enabled in multi core environment is
changed for performance evaluation. Each transaction
ac-cesses to 100 records which executes read or write operation, and each operation contains heavy computations. The ac-cessed records are randomly selected in the entire database.
Figure 4 is the result based of the change of the number of enabled core from 1 to 2, 4. Figure 4(a) shows that lock-ing method gets just 1.4% improved performance in 4 cores compared with 1 core. The reason is that locking method has huge overhead for lock management and has long critical sec-tion in the program. Long critical secsec-tion can enable only one core to work can at once even if processor has several cores. This is why locking method cannot get highly improved per-formance in multi core environment. Figure 4(b) shows that optimistic concurrency control gets performance gain up to 35% in 4 cores. And Figure 4(c) shows that transactional memory gets performance gain up to 71% in 4 cores. Trans-actional memory and optimistic concurrency control need to compete with other transactions only when the transactions want to execute conflict detection before completion. It also takes a very short time. This helps both transactional mem-ory and optimistic concurrency control to utilize more cores and get better performance gain than locking method in multi core environment.
We experiments very long transactions which access to 400 records and execute heavy computation for each write op-erations under 4 cores. Figure 5 shows the results of each con-currency control method. Execution time for locking method takes longer than it does in Figure 4(c) which transactions ac-cess to 100 records, but the difference is up to 15 seconds. Op-timistic concurrency control goes very fast for the case of read operation only, but it is 8 times slower than Figure 4(b) and locking method under other conditions. Transactional mem-ory is also slower than result of previous experiment. And it is slower than locking method when the rate of write operations is over 60%. For very long transactions, transactional mem-ory and optimistic concurrency control cause many restarts due to transaction conflicts. Thus locking method is better
0 1 2 3 4 5 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) TM 1 Core
TM 2 Core TM 4 Core
(a) Transactional Memory
0 2 4 6 8 10 12 14 16 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) OCC 1 Core
OCC 2 Core OCC 4 Core
(b) Optimistic Concurrency Control
45 46 47 48 49 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) Lock 1 Core
Lock 2 Core Lock 4 Core
(c) Locking Method
Figure 4: Execution time in Multi core
0 20 40 60 80 100 120 140 160 180 200 220 240 0 10 20 30 40 50 60 70 80 90 100
Execution Time (sec)
Read Rate(%) Transactional Memory Optimistic Concurrency Control Locking Method
Figure 5: Execution time for long transations
than other methods in the case of long transactions.
4.
CONCLUSION
We found that concurrency control using transactional mem-ory is better than locking method and optimistic concurrency control in multi core environment. Previous locking method has limitation in multi core environment. Even if the number of cores contained in processor is increased, locking method cannot use processor power appropriately because of the lock management overhead. Thus we need new concurrency con-trol method which can fully utilize cores contained in pro-cessor, and either transactional memory or optimistic con-currency control can be a good example. Both methods show good performance for the transactions which is short and con-tains more read operations than write operations. Especially, transactional memory shows really good performance in multi core environment.
In OLTP environment, many transactions simultaneously request operations and, the requested operations usually ac-cess to only a few records. Concurrency control using transac-tional memory is better than locking method in this situation. In addition, if the purpose of future processor development is to make multi core which contains more cores, transactional memory is much better than locking method.
However, transactional memory has been still studied and needs to be supplemented. To get better performance, we need transactional memory which is supported or imple-mented by hardware. Moreover, it is necessary to consider disk access and handling long transactions so that transac-tional memory can be apply to database systems based on disk.
ACKNOWLEDGMENT
This work was supported in part by MKE, Korea under ITRC NIPA-2010-(C1090-1021-0008), Seoul Metropolitan Govern-ment ‘Seoul R&BD Program (PA090903)’ and MEST, Korea under NRF Grant (NRF-2010-0025649).
5.
REFERENCES
[1] H. T. Kung and J. T. Robinson. On optimistic methods for concurrency control. In ACM Transactions on
DAtabase Systems, pages 213–226, 1981.
[2] D. B. Lomet. Process structuring, synchronization and recovery using atomic actions. In Proc. ACM Conf on
Language Design For Reliable Software, pages 128–137,
1977.
[3] M. Herlihy and J. E. B. Moss. Transactional memory: Architectural support for lock-free data structures. In
Proc. of the 20th Annual Intl. Symp. on Computer Architecture, pages 289–300, 1993.
[4] C. S. Ananian, Krste Asanovic, Bradley C. Kuszmaul, Charles E. Leiserson, and Sean Lie. Unbounded transactional memory. In Proc. of the Eleventh IEEE
Sump. on High-performance Computer Architecture,
2005.
[5] Lance Hammond, Vicky Wong, Mike Chen, Brian D. Carlstrom, John D. Davis, Ben Hertzberg, Manohar K. Prabhu, Honggo Wijaya, Christos Kozyrakis, and Kunle Olukotun. Transactional memory coherence and consistency. In Proc. of the 31st Annual Intl. Symp. on
Computer Architecture, 2004.
[6] Ravi Rajwar, Maurice Herlihy, , and Konrad Lai. Virtualizing transactional memory. In Proc. of the 32nd
Annual Intl. Sump. on computer Architecture, 2005.
[7] Tim Harris and Keir Fraser. Language support for lightweight transacitons. In Proc. of the 18th SIGPLAN
Conference on Object-Oriented Programming, Systems, Languages and Application(OOPSLA), 2003.
[8] Maurice Herlihy, Victor Luchangco, Mark Moir, and William Scherer III. Software transctional memory for dynamic sized data structures. In Twenty=Second
ACM Symp. on Principles of Distributed Computing,
2003.
[9] Nir Shavit and Dan Touitou. Software transactional memory. In Fourteenth ACM Symp. on Principles of
Distributed computing, 1995.
[10] K. P. Eswaran, J. N. Gray, R. A. Lorie, and I. L. Traiger. The notion of consistency and predicate locks in a database system. Communications of the ACM, 19(11):624–633, 1976.
[11] K. Moore, J. Bobba, M. Moravan, M. Hill, and D. Wood. Logtm: log-based transacional memory. In
Proc. of the Twelfth IEEE Symp. on High-Performance Computer Architecture, pages 254–265, 2006.
[12] Intel Corp. Intel C++ STM Compiler, Prototype Edition 3.0.