Download NESTED TRANSACTIONS FOR CONCURRENT EXECUTION OF

41
Threads are considered to be a single process (they have same PID), thus top-level
transaction and all the subtransactions are considered to be a single process. Now, if
parent transaction accesses an object or if any transaction in an hierarchy accesses an
object (thus getting object in the process memory), all other transactions can access
that object (due to the fact that every attempt to access an object, initially checks
for an EO for that object in process memory). Thus transactions without any access
privileges on an object can access it. To prevent this from happening, we forced
each access of an object to obtain a lock (or access permission) from the transaction
manager. As each lock entry along with other information has a TID (which is
unique for each transaction/subtransaction) of holder of the lock, the above problem
was avoided.
5.3.2 Lock Manager
Unlike in at transactions where each node in the lock table corresponds to the
lock held, in nested transactions nodes existing in the lock table may not correspond
to the lock held. In our implementation, if a transaction acquires a lock on an object,
then all its superiors will also (along with the transaction itself) be represented by a
node in lock table. Nodes corresponding to transactions (along a path from itself to
root) not holding a lock on an object give us information regarding holdsub, retainsub,
retain, and grantmode in their part of the subtree.
A straightforward implementation of the above increases the number of nodes
in a bucket (by a number depending on the depth of the tree). Also, the number
of times the lock table is accessed increases by the same amount (each acquire and
release would require us to update the information at all the superiors). Also, due to
collision, more than one object can hash to same bucket, thus eectively increasing
the search time. The number of nodes accessed in worst case can be given by: