Testing Database Transaction Concurrency Yuetang Deng Phyllis Frankl Zhongqiang Chen Department of Computer and Information Science Technical Report TR -CIS-2003-03 10/20/2003 Testing Database Transaction Concurrency1 Yuetang Deng Phyllis Frankl Zhongqiang Chen Department of Computer and Information Science Polytechnic University Brooklyn, NY 11201 USA {ytdeng, phyllis, zchen}@cis.poly.edu Abstract with transactions, comprising groups of related queries. This paper focuses on concurrency problems associated Database application programs are often designed to with multiple simultaneously running instances of an be executed concurrently by many users. By grouping application program. related database queries into transactions, DBMS Many database applications are designed to support systems can guarantee that each transaction satisfies the concurrent users. For example, in an airline reservation well-known ACID properties: Atomicity, Consistency, system, many clients can simultaneously purchase tickets. Isolation, and Durability. However, if a database To avoid simultaneous updates of the same data item and application is decomposed into transactions in an other potential concurrency problems, database incorrect manner, the application may fail when executed applications employ program units called transactions, concurrently due to potential offline concurrency consisting of a group of queries that access, and possibly problems. update, data items. The DBMS schedules query This paper presents a dataflow analysis technique for executions so as to insure data integrity at transaction identifying schedules of transaction execution aimed at boundaries while trying to utilize resources efficiently. revealing concurrency faults of this nature, along with Although the DBMS employs sophisticated techniques for controlling the DBMS or the application mechanisms to assure that transactions satisfy the ACID so that execution of transaction sequences follows properties – Atomicity, Consistency, Isolation, and generated schedules. The techniques have been integrated Durability – an application can still have concurrency- into AGENDA, a tool set for testing relational database related faults if the application programmer erroneously application programs. Preliminary empirical evaluation placed queries in separate transactions when they should is presented. have been executed as a unit. The focus of this paper is on detecting faults of this nature. 1. Introduction The rest of the paper is organized as follows. Section 2 introduces the background, including the AGENDA tool Database and transaction processing systems occupy a set for database application testing. Section 3 identifies central position in our information-based society. It is some typical transaction concurrency problems. Our essential that these systems function correctly and provide approach to test for concurrency problems is presented in acceptable performance. Substantial effort has been Section 4. Section 5 discusses the problems with devoted to insuring that the algorithms and data structures transaction atomicity/durability in database applications used by Database Management Systems (DBMSs) work and our solution. Section 6 presents preliminary empirical efficiently and protect the integrity of the data. However, evaluation. Section 7 describes the related work. Section relatively little attention has been given to developing 8 concludes with our contributions and discusses future systematic techniques for assuring the correctness of the work. related database application programs. Given the critical role these systems play in modern society, there is clearly 2. Background a need for new approaches to assess the quality of the database application programs. 2.1. Database Transaction To address this need, we have developed a systematic, partially-automatable approach and a tool set based on A transaction is a means by which an application this approach to testing database applications [4,5,6] programmer can package together a sequence of database Initially, we focused on problems associated with operations so that the database system can provide a individual queries. In [8] we explore problems dealing number of guarantees, known as the ACID properties of a 1 Supported in part by NSF grant CCR-9988354 transaction [11]. Atomicity ensures that the set of updates AGENDA takes as input the database schema of the contained in a transaction must succeed or fail as a unit. database on which the application runs, the application Consistency means that a transaction will transform the source code, and “sample value files”, containing some database from one consistent state to another. The suggested values for attributes. The tester interactively isolation property guarantees that partial effects of selects test heuristics and provides information about incomplete transactions should not be visible to other expected behaviors of test cases. Using this information, transactions. Durability means that effects of a committed AGENDA populates the database, generates inputs to the transaction are permanent and must not be lost because of application, executes the application on those inputs and later failure. Therefore, transactions can be used to solve checks some aspects of correctness of the resulting problems such as creation of inconsistent results, database state and the application output. concurrent execution errors within transactions and lost This approach is loosely based on the Category- results due to system crash [16]. Partition method [17]: the user supplies suggested values A database application program typically consists of for attributes, optionally partitioned into groups, which SQL statements embedded in a source language, such as we call data groups. The data are provided in the sample C or Java. Ends of transactions are delimited by the value files. The tool then produces meaningful keyword COMMIT (or ROLLBACK). Once a transaction combinations of these values in order to fill database begins execution, the DBMS assures that no other tables and provide input parameters to the application transaction executes a statement that interferes with this program. Data groups are used to distinguish values that transaction (e.g. by updating data being accessed by the are expected to result in different application behaviors. transaction) until the transaction commits or rolls back. For example, in a payroll system, different categories of The system can initiate a rollback when it enters a state in employees may be treated differently. Additional which ACID properties may be violated, either due to information about data groups, such as probability for overly optimistic scheduling decisions or to external selecting a group, can also be provided via sample value events such as system failure. When a rollback occurs, the files. system is restored to the state before execution of the Using these data groups and guided by heuristics, transaction. Once a transaction commits, all of the AGENDA produces a collection of test templates changes it has made to the database state become representing abstract test cases. The tester then provides permanent. information about the expected behavior of the In this paper, we consider application programs written application on tests represented by each test template. For in a high-level language such as C, with SQL statements example, the tester might specify that the application interspersed. The SQL statements may involve host should increase the salaries of employees in the “faculty” variables, which are variables declared in the host group by 10% and should not change any other attributes. program (host variables are preceded by colons). Multiple In order to control the explosion in the number of test clients may execute an application program concurrently. templates and to force the generation of particular kinds In this case, each client has its own host variables. The of templates, the tester selects heuristics. Finally, only “variable” shared by concurrently executing clients AGENDA instantiates the templates with specific test is the database. In this paper we do not consider stored values, executes the test cases and checks that the output procedures or shared variables arising through multi- and new database state are consistent with the expected threading within an application instance. behavior indicated by the tester. The architecture of AGENDA is shown in Figure 1. 2.2. AGENDA Tool Set The first component (AGENDA Parser) extracts relevant information from the application’s database In our previous work [4,5], we have discussed issues schema, the application queries, and tester-supplied arising in testing database systems, presented an approach sample value files, and then makes this information for testing database applications, and described available to the other four components by creating an AGENDA, a set of tools based on this approach. In internal database called AGENDA DB to store the testing such applications, the states of the database before extracted information. The AGENDA DB is used and/or and after the application’s execution play an important modified by the remaining four components. AGENDA role, along with the user’s input and the system output. A Parser is a modified version of from the open-source framework for testing database applications was DBMS Postgresql parser [18]. introduced. A complete tool set based on the framework The second component (State Generator) uses the has been prototyped. The components