COM1317 Transaction Processing

Projects


Final Project: Due May 27 Midnight

Project Description

Your goal in this project is to implement a lock manager and a transaction simulation program that simulates the lock request of multiple concurrently running transactions.

This project should be implemented in Java. Each transaction is simulated as one thread. Each transaction/thread reads in its own operation sequence from a file named id.txt where id is the transaction id. For example, transaction 1 will read in its schedule from "1.txt". All the transactions/threads are started randomly according to a random generator. After a transaction is started, it sends out lock request to lock manager in the order given in id.txt file.

The content in id.txt is given in the format of one operation each line. Each operation consists of two parts, the lock mode and the data object, which are seperated by empty space. For example, 1.txt. In our project, we consider two lock modes, read and write, represented as "r" and "w". You can think a data/resource object as a String object in Java.

The lock manager class should support the following two operations:

lock(Xid, Data, lockMode) throws DeadlockException
unlockAll(Xid)
Here Xid means the transaction id; data is the object to be locked and the lockMode is either "r" or "w". When a transaction commits or aborts, all the locks it has should be released by calling unlockAll(xid). The deadlocks are handled by timeout mechanism. When there is a deadlock, a DeadlockException is thrown. More details about the implementation of lock manager and its data structure can be found in Chapter 10 of our textbook. We will cover this part at the end of April before midterm. Notice that multiple threads may access the lock table at the same time. So make sure the lock table is "locked" before it is accessed. To implement the "lock" to the lock table, you can use synchronize mechanism in Java.

Note that there are two ways to "lock" the lock table. You can either lock the table including the RCBs chain until the operation ends. Or you can just lock the table temporarily. Once the pointer to the RCBs is available, the lock to the lock table is released. Both of them are correct. However, the first one has a bad concurrency. If you implement it in the first way, you will only receive partial credit. If you implement it using the temporary-locking idea, make sure that the RCB chain is locked before you operate on it.


Requirements

Students can work in groups. Each group has at most 2 people in it. Group members may share code with each other, but not with the students from other groups. Each group member must also submit a short statement in en envelope directly to the instructor with comments about the participation or whatsoever of the other group member in the project. Group members should have contact information of each other.

There are three milestones. The first two should be submitted in paper in class. The third one, i.e. the final project should be sent to jshan@ccs.neu.edu in a tarred file. For each submission, one copy is needed for each group.

Note:
(1) Submission of the first two milestones counts 5% and the submission of the third milestone counts the other 10%.
(2) Late hand-in will receive 20% late penalty.
(3) No late submission will be accepted after the final exam Wednesday June 4.


More details

(05/19/03)


Back to course homepage.

 

Last updated 05/08/03