Anda di halaman 1dari 2

CENTRAL LUZON STATE UNIVERSITY

COLLEGE OF ENGINEERING
DEPARTMENT OF INFORMATION TECHNOLOGY

NARRATIVE REPORT
of
Transaction and Lock Management Simulation

By:

De Leon, Jerome S.
Dela Cruz, Eduardo L.
Pajarillo, Dezza Joy D.
ACTIVITY
Transaction and Lock Management Simulation

The program is about the simulation of how DBMS handles transactions and how lock
management is done. It is written C language. It behaved like running multiple instances of
program by creating transactions.
The program is handling 5 tables and these are the Course, Class, Faculty, Room, and
Student and all transaction were logged into “trans.txt”. The moment the program runs, all records
in the text files is copied into corresponding structures, and record for each table is saved to array
on integer by the program. In order to use the tables, the user must issue command, “BEGIN
[transaction id];”, but the keyword “BEGIN” is case insensitive and “transaction id” is a single
alphanumeric character and no other same transaction id must exist unless it is already committed
in the program. After creating transaction, the program will get the current date and time and save
it as timestamp, and the user is now free to issue commands like INSERT INTO, UPDATE,
DELETE, SELECT and these are all case insensitive. The first time the user query command, and
if it is valid, the table used is save to the transaction and all succeeding queries must be the same
with the table used in the first query. The 5 query commands available to user behave like MySQL
but with limited functionalities.
If the user inserts record, the user must also input the table name and if it is valid by
checking if table name exists in the table list. When updating records, one limitation of the program
is the user need to update all fields. If user issues commands delete, select, and update then the
program ask the user to input ID only. All values inserted are recorded in the history log and when
the user commit the transaction then the program maps the queries in the history log and all
changes made is copied in the corresponding structures and then save it back to file.
The user can also create transaction one after another and last transaction can be later
committed by the user, but if the new transaction accesses the same table as the previous one, then
it is invalid, but if previous transaction only read the table and the next transaction tries to write to
it then it is valid. If transaction tries to write to given table then the table is locked by the program
and can be unlocked by committing the transaction who uses it.
There is also a time when user rollback the transaction and in this case, if the user tries to
roll back the transaction the it will be deleted to history log and no changes will be applied to the
table, and unlock the table if it locked.
The group learned about transactions and how lock is applied to object or table in order to
achieve the consistency of data, and common problems encountered by the database.