DATABASE CONCURRENCY CONTROL USING TRANSACTIONAL MEMORY : PERFORMANCE EVALUATION

DATABASE CONCURRENCY CONTROL USING TRANSACTIONAL MEMORY : PERFORMANCE EVALUATION Jeong Seung Yu a, Woon Hak Kang b, Hwan Soo Han c and Sang Won Lee d School of Info. & Comm. Engr. Sungkyunkwan University Suwon 44 746, Korea Altibase Corp. 182 13, Guro dong, Guro Gu Seoul, 152 847, Korea { a tinyisle, b woonagi319, c hhan, d swlee }@skku.edu ABSTRACT Recently, multi core processors are widely used. In multi core environment, programs should be parallelized to maximize 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 environment. Transactional memory has been proposed as an alternative. It provides lower overhead and more parallelism than locking method. In this paper, we evaluate the performance of concurrency control schemes using transactional memory, optimistic concurrency control and locking method respectively. Our experimental results show that transactional 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 words Database, Concurrency Control, Optimistic Concurrency Control, Transactional Memory, Multicore 1. INTRODUCTION In the past, processor development focused on finding a singlecore 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 multicore processor which contains many cores on one chip. This movement promotes the change of software development. Increasing clock speed has resulted in higher speed of application 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 multicore 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 resource 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 concurrency 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 simultaneously. Overhead caused by a lock is main reason for decreasing 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 locking method, optimistic concurrency control in database, and transactional memory in parallel programming. Section 3 discusses 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 programming 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 compatible. 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 waiting 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 Optimistic Concurrency Control [1]. It was introduced to supplement 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 contrast, the basic premise is that transactions running concurrently 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 outcomes 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 throughput 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 deadlock, it has starvation problem. When one transaction is aborted continually by another transaction, it is called starvation. 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 synchronization 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 problems with deadlock or managing and waiting for a lock like locking method in database system. Another problem with locking method is that it is difficult 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. Transactional 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 operations 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 different result from each other, transactional memory aborts execution results and restart to ensure atomicity. By ensuring that result of transaction executions is invisible to another transactions before it is completed, transactional memory guarantees isolation. This property is very similar to optimistic concurrency control in the database. Transactional memory is separated into hardware transactional memory [3, 4, 5, 6] and software transactional memory [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. Conflict Lazy Eager Version Management Lazy Eager OCC DBMSs[1] none Stanford TCC[5] MIT LTM[4] CCC DBMSs[1] 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 proposals use lazy versus eager management and conflict detection. Eager confliction detection is when confliction detection is executed 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 3.2 Performance on Singlecore For single core environment, only one core among four cores is enabled. Each transaction executes read or write operation for 1 records and each operation reads or writes a data which is 1 word size. The records to be accessed are selected randomly in the entire database. 5 Transactional memory is essentially similar to optimistic concurrency control. Both methods hope that most parallel accesses 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 accessing. These similarities provide the possibility to develop optimistic concurrency control in database system by using transactional memory. We can use transactional memory as a substitute for version management and conflict detection function in optimistic concurrency control. Furthermore, transactional memory has strong points of performance as well as convenience of program development. As previously mentioned, transactional memory can help to make the best use of multi core than locking method. Therefore, optimistic concurrency control using transactional memory can make better performance than locking method. 3.1 Evaluation Setup The computer used in the experiments has Intel i5-76 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, pages, and all data are main memory database management system stored in main memory. We ran 5 threads concurrently with 25, transactions which executes read or write operation to accessed records. In the experiments, Intel C++ Compiler Prototype Edition 3. [12], which is one of the software transactional memory, is used. Although it is slower than hardware transactional memory, it supports transactional memory with compiler 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. 4 3 2 1 1 9 8 7 Transactional Memory Optimistic Concurrency Control Locking Method 6 5 4 Figure 1: Execution time for short transactions Figure 1 shows the performance of each concurrency control in single core. X-axis is the rate of read operation among 1 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 operation only. It means locking method has huge overhead for lock management Transaction memory and optimistic concurrency control are much faster than locking method. The reason is that transactional memory and optimistic concurrency control are strong in short transactions. Figure 2(a), 2(b), and 2(c) show the result of the performance 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, however, 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 computations 64 times. Figure 3 shows the result of the performance of both transactional memory and optimistic concurrency control when each transaction accesses to 5 records. Execution time of both is increased more than the past experiment. The reason is that increased execution time by executing 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. 3 2 1

.3 TM 5 Records TM 3 Records TM 1 Records 9 8 7 Transactional Memory OCC.2.1 6 5 4 3 2 1 1 9 8 7 6 5 4 3 2 (a) Transactional Memory 1 1 9 8 7 6 5 4 3 2 1 Figure 3: Execution time on heavy computation.6.5.4.3.2.1 48 47 46 45 Figure 2: length 1 OCC 5 Records OCC 3 Records OCC 1 Records 9 8 7 6 5 4 (b) Optimistic Concurrency Control Lock 5 Records Lock 3 Records Lock 1 Records 1 9 8 7 6 5 4 (c) Locking Method Execution time on various transaction 3 3 2 2 1 1 3.3 Performance on Multicore The number of core enabled in multi core environment is changed for performance evaluation. Each transaction accesses to 1 records which executes read or write operation, and each operation contains heavy computations. The accessed 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 locking 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 section in the program. Long critical section 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 performance 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. Transactional 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 memory 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 4 records and execute heavy computation for each write operations under 4 cores. Figure 5 shows the results of each concurrency control method. Execution time for locking method takes longer than it does in Figure 4(c) which transactions access to 1 records, but the difference is up to 15 seconds. Optimistic 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 memory is also slower than result of previous experiment. And it is slower than locking method when the rate of write operations is over 6%. For very long transactions, transactional memory and optimistic concurrency control cause many restarts due to transaction conflicts. Thus locking method is better

5 4 TM 1 Core TM 2 Core TM 4 Core 24 22 2 18 Transactional Memory Optimistic Concurrency Control Locking Method 3 2 1 16 14 12 1 8 6 4 2 1 9 8 7 6 5 4 3 2 1 1 9 8 7 6 5 4 3 2 1 (a) Transactional Memory Figure 5: Execution time for long transations 16 OCC 1 Core OCC 2 Core OCC 4 Core than other methods in the case of long transactions. 14 12 4. CONCLUSION 1 8 6 4 2 49 48 47 46 45 1 9 8 7 6 5 4 (b) Optimistic Concurrency Control Lock 1 Core Lock 2 Core Lock 4 Core 3 2 1 We found that concurrency control using transactional memory 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 control method which can fully utilize cores contained in processor, and either transactional memory or optimistic concurrency control can be a good example. Both methods show good performance for the transactions which is short and contains 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 access to only a few records. Concurrency control using transactional 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 implemented by hardware. Moreover, it is necessary to consider disk access and handling long transactions so that transactional memory can be apply to database systems based on disk. 1 9 8 7 6 5 4 3 2 1 (c) Locking Method Figure 4: Execution time in Multi core ACKNOWLEDGMENT This work was supported in part by MKE, Korea under ITRC NIPA-21-(C19-121-8), Seoul Metropolitan Government Seoul R&BD Program (PA993) and MEST, Korea under NRF Grant (NRF-21-25649).

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 2th Annual Intl. Symp. on Computer Architecture, pages 289 3, 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, 25. [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, 24. [6] Ravi Rajwar, Maurice Herlihy,, and Konrad Lai. Virtualizing transactional memory. In Proc. of the 32nd Annual Intl. Sump. on computer Architecture, 25. [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), 23. [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, 23. [9] Nir Shavit and Dan Touitou. Software transactional memory. In Fourteenth ACM Symp. on Principles of Distributed computing, 1995. [1] 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, 26. [12] Intel Corp. Intel C++ STM Compiler, Prototype Edition 3.. http://software.intel.com/enus/articles/intel-c-stm-compiler-prototype-edition-2.