|
CS4432 (DBII) - Project #3 on Lock Management
|
OUT: Tuesday, April 17, 2001.
DUE: 12:00 am (midnight) on Sunday, April 29th, 2001.
TO BE SUBMITTED VIA MyWPI
POINTS: max of 100pts.
To give you a reprieve from all those string manipulations
and file management headaches, the third and final project in CS4432
will be the development of HappyLocker, a system
that is responsible for the management of locks for shared
resources (such as tuple access) in a database.
HappyLocker is intended to be a stand-alone system used for
transaction-management purposes in a database system.
HappyLocker is not to be integrated
with your previous project #1 or project #2.
And, what may be even better news for you, you are free to choose
between JAVA, C++ or C.
To simplify the project,
your lock manager
HappyLocker will receive lock requests from stdin, and will
output text describing the outcome of those requests to stdout.
Input for the HappyLocker System
Each line of the input is a request to the lock manager. Each request may contain a transaction
ID (transID), which is an ASCII representation of a number between 0 and 255; and an object
name (object) which is an
alphanumeric string of at most 10 characters. Following are the
possible requests and their formats:
-
STXN transID: starts a transaction with id transID.
-
ETXN transID: ends the transaction with id transID. When this request is received, your program
should release all locks held by transID as well as cancel any outstanding requests for locks.
-
SLOC transID object: transaction transID is requesting a shared lock on object. There are two
possible outcomes for this request, the lock is either granted or the transaction is put in the
waiting list for the lock.
-
XLOC transID object: transaction transID is requesting an exclusive lock on object. As in the
previous case, the lock would be granted or the transaction must wait. This request can be issued
by a transaction that wishes to upgrade a lock from shared to exclusive.
-
ULOC transID object: transaction transID releases its lock on object. After releasing the lock, it
should be granted to a waiting transaction (if any). You can define your own policy for granting
locks (FIFO, LIFO, random, etc.); but you should justify your decision in the documentation
(remember to consider the case of a transaction that upgrades a lock
from shared to exclusive).
Output for the HappyLocker System
The output for each request will start with the request being considered, followed by a colon and
one or more messages. In the following table we present a list of possible messages for each request.
You can change the format of the messages or add extra messages if you want.
|
Request
|
Possible Messages
|
|
STXN
|
Transaction started
|
|
SLOC
|
Lock granted
Waiting for lock (X-lock held by: <trans_ID>)
|
|
XLOC
|
Lock granted
Upgrade to XLOC granted
Waiting for lock (S-lock held by: <transID > . . . < transID>)
Waiting for lock (X-lock held by: <trans_ID>)
|
|
ETXN
|
Transaction ended
Lock released
Lock granted to <transID > . . . < transID>
|
|
ULOC
|
Lock released
Lock granted to <transID > . . . < transID>
|
Sample Input and Output
|
Input
|
Output
|
|
STXN1
|
STXN 1 : Transaction 1 started
|
|
STXN 2
|
STXN 2 : Transaction 2 started
|
|
SLOC 1 A
|
SLOC 1 A: Lock granted |
|
XLOC 2 A |
XLOC 2 A: Waiting for lock (S-lock held by: 1) |
|
ULOC 1 A |
ULOC 1 A: Lock released
X-Lock granted to 2 |
|
XLOC 1 B |
XLOC 1 B: Lock granted
|
|
XLOC 2 B |
XLOC 2 B: Waiting for lock (X-lock held by: 1)
|
|
XLOC 1 A
|
XLOC 1 A: Waiting for lock (X-lock held by: 2)
|
|
ETXN 1
|
ETXN 1 : Transaction 1 ended
Release X-lock on B
X-Lock on B granted to 2
|
|
ULOC 2 A
|
ULOC 2 A: Lock released
|
|
ETXN 2
|
ETXN 2 : Transaction 2 ended
|
Functionality, Data Structures and Algorithms
Basic Design of Lock Table and Manager.
For your program, you need to implement a lock table.
You can use your own design for this system.
Your lock table will reside in memory and will contain
information for every outstanding lock in the system. The minimum
information that you should
maintain is which transactions have the lock and in which mode; as well as
which transactions are waiting for the lock.
Deadlock Detection.
As additional feature,
after processing a request for an exclusive or shared lock your
program should report any deadlocks
(it does not necessarily need to prevent or solve them).
For example, in the sample input
above, a deadlock is created after processing
XLOC 1 A . At that moment, your program can print a
message like ``Deadlock detected (involving transactions: 1 and 2)''. For your deadlock
detection algorithm, do not reinvent the wheel.
Instead, you are encouraged to use an algorithm that
detects cycles in a graph from an standard textbook on algorithms.
Error Handling.
Furthermore, you should provide some solid error handling to your
lock manager. That is, you should be testing your program both
with some legal and well-formed schedules as input as well
as with input composed of an ill-formed schedule.
One example of an ill-formed schedule are lock-requests arriving for
transaction that did already terminate via an END-TRANSACTION
(ETXN) command.
Another one are lock-requests arriving for
a transaction
that currently is not active, i.e., there is no current
START-TRANSACTION (STXN) for this given transaction id in the system.
Also, we will need to double-check in the input that
no requests (except
END-TRANSACTION (ETXN))
will be made for a transaction that it is still waiting for a lock.
If you identify such an illegal operations in the iput schedule,
you need to flag the error in the input and then
do proper error handling. You may for example
decide to then terminate the scheduling (and thus assume
that some roll-back of all active transactions will occur
by a program not part of your project#3).
You are also free to choose alternative
repair decisions but then you must
clearly justify your choice of strategy.
Documentation
Each team is
expected to submit a description of your design
(data structures and algorithms)
in a plain text file
called README, as
well as to include comments in the
code. For the format of this document, please refer to CS
Department Standard Document.
Also, you have to provide a complete
set of testing cases you have
worked with to evaluate your program, including testing runs scripting
successful runs of the respective tests.
A discussion of what
features work and do not work must be included.
Grading
The grade of your program will be based on four aspects:
- Functionality - that the program correctly implements the specifications.
- Quality - elegant design, and modularity and clarity of code.
- Documentation - as described above, including discussion of your design choices and limitations and commenting of your code.
- Evaluation - testing quality includes a
clear description of the test runs utilized
for assuring the functionality of your system, as well as
scripts clearly and completely illustrating that your program works
for all cases and with proper error handling.
[ We may provide you with one extra test file
a few days before due date, in which case we
expect you to turn in also the results of running your program
on our test file. ]
Submission
Submission of the assignment will take place electronically via myWPI.
Each team must submit one copy of their HappyLocker system
into myWPI.
Your complete work including your README documentation file must be submitted in
one package
that has been zipped. Several individual files by one team
will not be accepted.
Make sure that your zipped file has a clear name of the
form "project3.team-number".
Also, please make sure to include on top of
each of your files in the zipped file the following to avoid any confusion:
"CS4432-project#3, your names and the number of your team (to be
gotten from our CS4432 website).