Jump to content

Why's this locking schedule an incorrect one?

Recommended Posts

Time | T9 Operation     | T10 Operation
1    | Read x           | 
2    | Write x          | 
3    |           		| Read x
4    |                  | Write x
5    | 		            | Read y
6    |                  | Write y
7    | Read y           | Commit
8    | Write y          | 
9    | Commit           | 

This is a topic from Database Systems by Thomas M. Connolly and Carolyn E. Begg.

Then, he talks about locking:

Here's the gist about it.

- There are shared lock and exclusive lock.

- Lock is granted as per lock compatibility matrix.

- Lock can be upgraded and downgraded.

(Remember author haven't started 2-PL yet)

Then the author talks something which is my question..

Incorrect Locking Schedule

A valid schedule that may be employed using the previous locking rules is:


But I see tons of discrepancies in this locked schedule contradictory to what the author said earlier.

1) As per the book earlier, "A transaction continues to hold a lock until it explicitly releases it either during execution of when it terminates(aborts or commits)", Why is the lock being released before commit(T10) and commit(T9) in this case? Did author just meant that the lock was voluntarily removed by the transaction before committing?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.