Q1.
An. i) Let’s analyze each schedule:
a) T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Commit
• This schedule is not conflict serializable because there is a write-read
conflict between T1 and T2 on X that causes the schedule to be non-
serializable. The precedence graph would have a cycle.
• It is not view serializable because T2 reads the result of a write by T1, but
in a serial schedule, T2 would have to read the initial value of X.
• It is recoverable because all transactions that a transaction T may depend
on commit before T commits.
• It avoids cascading aborts because every transaction only reads items that
were written by committed transactions.
• It is strict because every transaction only reads and writes items that were
written by committed transactions.
b) T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Abort
• This schedule is not conflict serializable because there is a write-read
conflict between T1 and T2 on X that causes the schedule to be non-
serializable. The precedence graph would have a cycle.
• It is not view serializable because T2 reads the result of a write by T1, but
in a serial schedule, T2 would have to read the initial value of X.
• It is not recoverable because T2 commits before T1, and T2 reads an item
written by T1. If T1 aborts, T2 would have already committed, violating
recoverability.
• It does not avoid cascading aborts because T2 reads an uncommitted
change from T1.
• It is not strict because T2 reads an uncommitted change from T1.
c) T2: R(X), T3:W(X), T3:Commit, T1:W(Y), T1:Commit, T2:R(Y), T2:W(Z),
T2:Commit
• This schedule is conflict serializable. The precedence graph (T2->T3->T1-
>T2) does not have a cycle.
• It is view serializable because it is conflict serializable.
• It is recoverable because all transactions that a transaction T may depend
on commit before T commits.
• It avoids cascading aborts because every transaction only reads items that
were written by committed transactions.
• It is strict because every transaction only reads and writes items that were
written by committed transactions.
d) T1:R(X), T2:W(X), T1:W(X), T3:R(X), T1:Commit, T2:Commit, T3:Commit
• This schedule is not conflict serializable because there is a write-write
conflict between T1 and T2 on X that causes the schedule to be non-
serializable. The precedence graph would have a cycle.
• It is not view serializable because T2 writes X after T1 reads it, but in a
serial schedule, T2 would have to write X before T1 reads it.
• It is recoverable because all transactions that a transaction T may depend
on commit before T commits.
• It avoids cascading aborts because every transaction only reads items that
were written by committed transactions.
• It is not strict because T1 reads an uncommitted change from T2.
a) T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Commit
• The precedence graph would have a single edge from T1 to T2 because T2 reads a value
written by T1.
b) T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Abort
• The precedence graph would have a single edge from T1 to T2 because T2 reads a value
written by T1.
c) T2: R(X), T3:W(X), T3:Commit, T1:W(Y), T1:Commit, T2:R(Y), T2:W(Z), T2:Commit
• The precedence graph would have two edges: one from T2 to T3 because T3 writes a value
read by T2, and another from T3 to T1 because T1 writes a value read by T3.
d) T1:R(X), T2:W(X), T1:W(X), T3:R(X), T1:Commit, T2:Commit, T3:Commit
• The precedence graph would have three edges: one from T1 to T2 because T2 writes a value
read by T1, another from T2 to T1 because T1 writes a value written by T2, and a third from
T1 to T3 because T3 reads a value written by T1. This forms a cycle in the graph, indicating a
conflict.
ii) Let’s analyze the schedules:
S1: r1(w), w1(x), r1(y), w1(y), r1(x), w2(x), c2, c1
• This schedule is recoverable because all transactions that a transaction T
may depend on commit before T commits.
S2: r1(x), w1(x), r2(x), r1(y), w2(x), w1(y), c1, c2
• This schedule is not recoverable because T2 reads an item written by T1,
and T2 commits before T1. If T1 aborts, T2 would have already committed,
violating recoverability.
Q2.
An.
a) In a timestamp-based concurrency control scheme, transactions are ordered by
their timestamps, and older transactions get priority over newer ones. Given the
timestamps t1<t2<t3, let’s analyze the schedule:
• T1: read(A)
• T2: read(B)
• T1: write©
• T3: read(B)
• T3: read©
• T2: write(B)
• T3: write(A)
Here’s the analysis:
• T1 reads A. This operation is allowed because no other transaction has
written A.
• T2 reads B. This operation is allowed because no other transaction has
written B.
• T1 writes C. This operation is allowed because no other transaction has read
or written C.
• T3 reads B. This operation is allowed because T2, which is older, has not
written B.
• T3 reads C. This operation is not allowed because T1, which is older, has
written C. According to the timestamp ordering scheme, a younger
transaction (T3) cannot read a data item that an older transaction (T1) has
written. Therefore, T3 will be rolled back.
So, in this case, transaction T3 will be rolled back due to the read operation on C
after T1 has written C. The schedule will not go through as it is, due to this
conflict. After rolling back T3, the schedule can proceed with just T1 and T2. If T3
is restarted later with a new timestamp, it will need to respect the ordering of the
other transactions to avoid conflicts.
b) Based on the image details you provided, the sequence of events is as follows:
• T2: Read B
• T4: Read D
• T2: Read E
• T2: Write E
• T3: Read F
• T2: Read F
• T1: Read C
• T5: Read A
• T5: Write A
• T1: Read E
• T5: Read C
• T3: Read A
• T5: Write C
• T2: Write F
• T4: Read A
Here’s how the wait-for graph would look based on the sequence of events:
• T2 reads B, then T4 reads D. Since these are different items, there’s no edge between
T2 and T4.
• T2 reads E, then writes E. T1 then reads E. This implies T1 is waiting for T2, so we
draw an edge from T1 to T2.
• T3 reads F, then T2 reads F. This implies T2 is waiting for T3, so we draw an edge
from T2 to T3.
• T1 reads C, then T5 reads A and writes A. This implies T5 is waiting for T1, so we draw
an edge from T5 to T1.
• T1 reads E, then T5 reads C and T3 reads A. This implies T5 and T3 are waiting for T1,
so we draw edges from T5 and T3 to T1.
• T5 writes C, then T2 writes F. This implies T2 is waiting for T5, so we draw an edge
from T2 to T5.
• T4 reads A. This implies T4 is waiting for T5, so we draw an edge from T4 to T5.
Now, if we look at the wait-for graph, we can see that there is a cycle involving T1,
T2, T3, T4, and T5. A cycle in a wait-for graph indicates a deadlock. Therefore, the
transactions are in a deadlock.
C) Yes, there is a potential for deadlock in this code. A deadlock can occur when
two or more threads need the same resources but obtain them in a different order.
If a thread holds one resource and requests another held by a second thread, while
the second thread is waiting for the resource held by the first thread, a deadlock
occurs.
In this case, T1 locks P and then tries to lock Q, while T2 locks Q and then tries to
lock P. If T1 and T2 both get to their first lock statement at the same time, T1 will
lock P and T2 will lock Q. Then, they’ll each wait for the other to release their
lock, resulting in a deadlock.
To avoid this deadlock, we can ensure that both T1 and T2 threads lock the
resources (P, Q) in the same order. For example, both should lock P first and then
Q or vice versa. Here’s the modified code:
T1:
Lock(X(P))
Lock_X(Q)
Read(P)
P=P-100
Write(P)
Read(Q)
Q=Q+100
Write(Q)
UnLock(P)
UnLock(Q)
T2:
Lock(S(P))
Lock_S(Q)
Read(Q)
Read(P)
Display(P+Q)
UnLock(Q)
UnLock(P)
In this modified code, both T1 and T2 lock P first and then Q. This ensures that
they won’t end up in a situation where each is holding a resource that the other
needs, thus avoiding a deadlock. Please note that this solution assumes that the
locks are reentrant, i.e., a thread can lock a resource it already has locked without
blocking. If the locks are not reentrant, additional care must be taken to avoid
deadlocks.
Q3.
An.
a) (i) In Serializable isolation level, transactions are completely isolated from each
other. They are executed one after the other. So, the possible final amounts for Bob
are:
• If T1 executes first, then T2:
13.5∗13.5∗2000∗0.5∗1.2=21870013.5∗13.5∗2000∗0.5∗1.2=218700
• If T2 executes first, then T1:
0.5∗1.2∗2000∗13.5∗13.5=2187000.5∗1.2∗2000∗13.5∗13.5=218700
(ii) In Read Committed isolation level, a transaction may read data from a row
that has been modified by another running transaction but not yet committed. So,
the possible final amounts for Bob are:
• If T1’s B1 executes before T2’s C1 and C2, and then T1’s B2 executes:
13.5∗2000∗0.5∗1.2∗13.5=21870013.5∗2000∗0.5∗1.2∗13.5=218700
• If T2’s C1 executes before T1’s B1 and B2, and then T2’s C2 executes:
0.5∗2000∗13.5∗13.5∗1.2=2187000.5∗2000∗13.5∗13.5∗1.2=218700
• If T1’s B1 and T2’s C1 execute before T1’s B2 and T2’s C2:
13.5∗2000∗0.5∗13.5∗1.2=21870013.5∗2000∗0.5∗13.5∗1.2=218700
• If T1’s B1 and T2’s C1 and C2 execute before T1’s B2:
13.5∗2000∗0.5∗1.2∗13.5=21870013.5∗2000∗0.5∗1.2∗13.5=218700
(iii) In this case, T1 is in Read Committed and T2 is in Read Uncommitted
isolation level. So, the possible final amounts for Bob are:
• If T1’s B1 executes before T2’s C1 and C2, and then T1’s B2 executes:
13.5∗2000∗0.5∗1.2∗13.5=21870013.5∗2000∗0.5∗1.2∗13.5=218700
• If T2’s C1 executes before T1’s B1 and B2, and then T2’s C2 executes:
0.5∗2000∗13.5∗13.5∗1.2=2187000.5∗2000∗13.5∗13.5∗1.2=218700
• If T1’s B1 and T2’s C1 execute before T1’s B2 and T2’s C2:
13.5∗2000∗0.5∗13.5∗1.2=21870013.5∗2000∗0.5∗13.5∗1.2=218700
• If T1’s B1 and T2’s C1 and C2 execute before T1’s B2:
13.5∗2000∗0.5∗1.2∗13.5=21870013.5∗2000∗0.5∗1.2∗13.5=218700
b) (i) The redo list contains: T0, T1, T2 The undo list contains: T3
(ii) The values of each data item are:
• Interest: 6 (T3 was aborted)
• Principle: 400
• Amount: 600
(iii) The order of Transactions to recover are: T0, T1, T2, T3
Q4.
An.
Sure, here’s how you can design and implement the access matrix for the database
of JK ISP company:
Database objects required:
• Tables: Customer Records, Service Packages, Bill Reminders, Technical
Issues, Complaints, Monthly Bills.
• Stored Procedures (SP): To handle complex queries related to billing,
complaints resolution, etc.
• Triggers: To automatically send bill reminders, escalate unresolved
technical issues, etc.
• Views: For different users to view data according to their access rights.
• Forms: For data entry like adding new customers, logging technical issues,
etc.
i). Design the access matrix:
• Manager:
o Read: Yes
o Write: Yes
o Update: Yes
o Delete: Yes
• Senior Tech:
o Read: Yes
o Write: No
o Update: Yes
o Delete: No
• Supervisor:
o Read: Yes
o Write: No
o Update (specifically for bills): Yes
o Delete (specifically for bills): No
• Customer Service Person:
o Read (only view data): Yes
o Write, Update, Delete : No
ii). Implement the access matrix: The implementation of the access matrix can be
done using roles and permissions in SQL or any other database management
system. Here is a simplified version:
-- Manager Role Permissions --
GRANT SELECT, INSERT, UPDATE, DELETE ON CustomerRecords TO Manager;
-- Senior Tech Role Permissions --
GRANT SELECT, UPDATE ON CustomerRecords TO SeniorTech;
-- Supervisor Role Permissions --
GRANT SELECT ON CustomerRecords TO Supervisor;
GRANT UPDATE ON Bills TO Supervisor WHERE condition; -- Condition to allow
corrections if needed.
-- Customer Service Person Role Permissions --
GRANT SELECT ON ViewOnlyData TO CustomerServicePerson; -- Assuming there
is a view created for read-only data.
Please note that this is a simplified version and actual implementation may require
more detailed access control depending on the specific needs of the system. Also,
the condition in the Supervisor’s UPDATE permission needs to be replaced with
the actual condition for bill corrections.
