SlideShare a Scribd company logo
Assignment 6 - Solution
Problem 1
Suppose a transaction sets an intention-write lock on a file and
later sets a write lock on a record of the file.
Is it safe for the transaction to release the intention-write lock
before it commits? Why?
No it’s not safe. Suppose record x is contained in file F. Consider
the following execution:
iwl1[F] wl1[x] w1[x] iwu1[F] rl2[F] r2[x] w1[x] wu1[x] c1 ru2[F] c2
Transaction T1 writes x twice, once before r2[x] and once
afterwards, so the result isn’t serializable.
Problem 2
The multi-granularity locking protocol requires that if a
transaction has a w or iw lock on a data item x, then it must have
an iw lock on x’s parent.
2.A. Is it correct for a transaction to hold an r lock on x’s parent
instead? Either explain why it’s correct or give an example where
it fails.
• No, it is incorrect.
• This would allow:
• T1 to read lock file F
• (giving it permission to read every record in F),
• T2 to read lock F and write lock a record in F, such as x.
• Thus T1 would implicitly have a read lock on x that conflicts
with T2’s write lock on x.
2.B. Redo question (2.A), replacing “r lock” by “w lock”.
Is it correct for a transaction to hold an w lock on x’s parent
instead?
• Yes, it is correct.
• Assuming the given protocol is correct using iw locks, then w
locks must work too
• w lock is strictly stronger than an iw lock.
• By “stronger,” we mean that any lock type that conflicts with an
iw lock also conflicts with a w lock.
• You might think it’s incorrect because it needlessly prevents
certain operations from running.
• This is a performance problem, but not incorrect, in the sense
of breaking a conflict or an ACID property.
2.C. Assuming the lock graph is a tree, suggest a case where it
would be useful to set such a w lock as in (2.B) (whether or not
it’s correct).
In cases where the data manager would escalate fine-grained w
locks to coarse-grained locks, then using the coarse-grained w as
parent will perform slightly better by avoiding the escalation cost
and the cost of needlessly setting the fine-grained locks before
escalating.
Problem 3
Consider the following database table, which supports a multiversion
concurrency control.
Suppose the commit list contains {1,2,3,4,6} and there are no active
transactions.
TID Prev TID Account# Balance
1 Null 10 100
3 1 10 200
1 Null 11 300
4 1 11 400
5 4 11 350
6 Null 12 500
3.A. What is the state of the table after running the following
transaction?:
TID=8: Increment the balance of account 10 by 100;
Delete account 12;
Insert account 13 with balance 700.
The database state after transaction 8 commits
TID Prev TID Account# Balance
1 Null 10 100
3 1 10 200
8 3 10 300
1 Null 11 300
4 1 11 400
5 4 11 350
6 Null 12 500
8 6 12 deleted
8 Null 13 700
TID Prev TID Account# Balance
1 Null 10 100
3 1 10 200
1 Null 11 300
4 1 11 400
5 4 11 350
6 Null 12 500
3.B. Suppose a read-only query with TID=7 reads all the
accounts. It starts executing before executing transaction 8
starts executing and finishes after transaction 8 commits
(same transaction 8 as part (a)). Which versions of which rows
does it read?
3.B.
• When it started executing, transaction 7 read the following
commit list: {1,2,3,4,6}.
• It read the following:
• version TID 3 of Account 10,
• version TID 4 of Account 11 (because 5 didn’t commit)
• version TID 6 of account 12.
• It does not see any of transaction 8’s updates because
transaction 8 was not on the commit list when it started.
TID Prev TID Account# Balance
1 Null 10 100
3 1 10 200
8 3 10 300
1 Null 11 300
4 1 11 400
5 4 11 350
6 Null 12 500
8 6 12 deleted
8 Null 13 700
3.C. After transactions 7 and 8 have finished and no other
transactions are active, suppose we garbage collect all of the
versions that aren’t needed. Assuming transaction ids
increase monotonically with respect time, what does the table
look like after the garbage collection step?
The garbage collector keeps the last committed update of each
account:
TID Prev TID Account# Balance
8 Null 10 300
4 Null 11 400
8 Null 13 700
TID Prev TID Account# Balance
1 Null 10 100
3 1 10 200
8 3 10 300
1 Null 11 300
4 1 11 400
5 4 11 350
6 Null 12 500
8 6 12 deleted
8 Null 13 700
Problem 4
Suppose file F contains a sequence of fixed-length records, and
F’s descriptor includes a count of the number of records in F,
which is used to find the end of F. Consider the following two
transactions:
• T1:
• Scan F, returning all the records in F
• Read(x)
• T2:
• Insert a record into F
• Write(x)
Data item x is not in F. Both transactions are two-phase locked
(locking records in F and x), but neither transaction locks count.
4.A. Given an example of a non-serializable execution of T1
and T2. Explain why it’s non- serializable.
1. T1: Scan F, returning all the records in F
2. T2: Insert a record into F
3. T2: Write(x)
4. Commit2
5. T1: Read(x)
• The first two operations imply and T1 precedes T2, but since
they don’t lock count, the first operation doesn’t cause the
second one to be delayed.
• The third and fifth operations on x conflict, which imply that
T2 precedes T1.
• So the execution isn’t SR.
4.B. Explain why this is an example of the phantom problem.
• T1:
• Scan F, returning all the records in F
• Read(x)
• T2:
• Insert a record into F
• Write(x)
T2’s insertion into F is a phantom record. T1’s scan doesn’t see
the record, but T1’s Read(x) indirectly sees the result in data
item x (assuming the value of x is a function of the records in F).

More Related Content

PPTX
Study Notes: Google Percolator
DOCX
Multiversion Concurrency Control Techniques
PPT
OS Process Synchronization, semaphore and Monitors
PPT
Ch7 OS
 
PPT
Peterson Critical Section Problem Solution
PPTX
Validation based protocol
PPTX
Vim knowhow
Study Notes: Google Percolator
Multiversion Concurrency Control Techniques
OS Process Synchronization, semaphore and Monitors
Ch7 OS
 
Peterson Critical Section Problem Solution
Validation based protocol
Vim knowhow

What's hot (11)

PPT
Process Synchronization
PDF
Synchronize access to shared mutable data
PPTX
C# Loops
PPT
Chapter 6 - Process Synchronization
PDF
Basic constructs ii
PPTX
protocols of concurrency control
PDF
Python - Lecture 10
PDF
Semaphores
PDF
Distributed Computing On Topics of: Leader election + Byzantine algorithms)
PPTX
Process synchronization
PDF
Distributed Computing Set 3 - Topics of non-Byzantine Consensus
Process Synchronization
Synchronize access to shared mutable data
C# Loops
Chapter 6 - Process Synchronization
Basic constructs ii
protocols of concurrency control
Python - Lecture 10
Semaphores
Distributed Computing On Topics of: Leader election + Byzantine algorithms)
Process synchronization
Distributed Computing Set 3 - Topics of non-Byzantine Consensus
Ad

Viewers also liked (11)

DOCX
Info ensayo deber
DOCX
Data profiling
DOCX
Info ensayo deber
PDF
Conociendo la Cencia Medica
DOCX
Smartphone
PPTX
Lign105 guide
PDF
Gaceta1148
PDF
Hóa vô cơ tập 2 - Hoàng Nhâm
PDF
Resumen unit 5 where i live social science
PDF
Part of the pipeline-why continuous testing is essential - velocity conf
PDF
Csc and tesda equivalency program
Info ensayo deber
Data profiling
Info ensayo deber
Conociendo la Cencia Medica
Smartphone
Lign105 guide
Gaceta1148
Hóa vô cơ tập 2 - Hoàng Nhâm
Resumen unit 5 where i live social science
Part of the pipeline-why continuous testing is essential - velocity conf
Csc and tesda equivalency program
Ad

Similar to Solution6.2012 (20)

PDF
Assignment.6.2012
PPT
3 concurrencycontrolone
PPT
06 07 lock
PPT
concurrency-control
PDF
Cs501 concurrency
PPTX
recoverability and serializability dbms
PPTX
Concurrency control
PPTX
DBMS Pravin concurrency control technique.pptx
PDF
3 concurrency controlone_v3
PPTX
BCT 2312 - Chapter 3 - Concurrency Control Techniques in DBMSs.pptx
PPTX
Concurrency Control in Databases.Database management systems
PPTX
DBMS Presentation.pptx
PDF
PPT-concurrency Control database management system DBMS concurrent control (U...
PPTX
Concurrency Control & Deadlock Handling
PDF
Concurrency Control in Database Management System
PPTX
Concurrency control!
PPTX
db unit 4 dbms protocols in transaction
PPTX
CHapter four database managementm04.pptx
PPT
Concurrency control
PPT
Chapter18
Assignment.6.2012
3 concurrencycontrolone
06 07 lock
concurrency-control
Cs501 concurrency
recoverability and serializability dbms
Concurrency control
DBMS Pravin concurrency control technique.pptx
3 concurrency controlone_v3
BCT 2312 - Chapter 3 - Concurrency Control Techniques in DBMSs.pptx
Concurrency Control in Databases.Database management systems
DBMS Presentation.pptx
PPT-concurrency Control database management system DBMS concurrent control (U...
Concurrency Control & Deadlock Handling
Concurrency Control in Database Management System
Concurrency control!
db unit 4 dbms protocols in transaction
CHapter four database managementm04.pptx
Concurrency control
Chapter18

More from ashish61_scs (20)

PDF
7 concurrency controltwo
PDF
Transactions
PPT
22 levine
PDF
21 domino mohan-1
PPT
20 access paths
PPT
19 structured files
PPT
18 philbe replication stanford99
PDF
17 wics99 harkey
PPT
16 greg hope_com_wics
PPT
15 bufferand records
PPT
14 turing wics
PPT
14 scaleabilty wics
PPT
13 tm adv
PPT
PPT
10b rm
PPT
10a log
PPT
09 workflow
PPT
08 message and_queues_dieter_gawlick
PPT
05 tp mon_orbs
PPT
04 transaction models
7 concurrency controltwo
Transactions
22 levine
21 domino mohan-1
20 access paths
19 structured files
18 philbe replication stanford99
17 wics99 harkey
16 greg hope_com_wics
15 bufferand records
14 turing wics
14 scaleabilty wics
13 tm adv
10b rm
10a log
09 workflow
08 message and_queues_dieter_gawlick
05 tp mon_orbs
04 transaction models

Solution6.2012

  • 1. Assignment 6 - Solution Problem 1 Suppose a transaction sets an intention-write lock on a file and later sets a write lock on a record of the file. Is it safe for the transaction to release the intention-write lock before it commits? Why? No it’s not safe. Suppose record x is contained in file F. Consider the following execution: iwl1[F] wl1[x] w1[x] iwu1[F] rl2[F] r2[x] w1[x] wu1[x] c1 ru2[F] c2 Transaction T1 writes x twice, once before r2[x] and once afterwards, so the result isn’t serializable.
  • 2. Problem 2 The multi-granularity locking protocol requires that if a transaction has a w or iw lock on a data item x, then it must have an iw lock on x’s parent. 2.A. Is it correct for a transaction to hold an r lock on x’s parent instead? Either explain why it’s correct or give an example where it fails. • No, it is incorrect. • This would allow: • T1 to read lock file F • (giving it permission to read every record in F), • T2 to read lock F and write lock a record in F, such as x. • Thus T1 would implicitly have a read lock on x that conflicts with T2’s write lock on x.
  • 3. 2.B. Redo question (2.A), replacing “r lock” by “w lock”. Is it correct for a transaction to hold an w lock on x’s parent instead? • Yes, it is correct. • Assuming the given protocol is correct using iw locks, then w locks must work too • w lock is strictly stronger than an iw lock. • By “stronger,” we mean that any lock type that conflicts with an iw lock also conflicts with a w lock. • You might think it’s incorrect because it needlessly prevents certain operations from running. • This is a performance problem, but not incorrect, in the sense of breaking a conflict or an ACID property.
  • 4. 2.C. Assuming the lock graph is a tree, suggest a case where it would be useful to set such a w lock as in (2.B) (whether or not it’s correct). In cases where the data manager would escalate fine-grained w locks to coarse-grained locks, then using the coarse-grained w as parent will perform slightly better by avoiding the escalation cost and the cost of needlessly setting the fine-grained locks before escalating.
  • 5. Problem 3 Consider the following database table, which supports a multiversion concurrency control. Suppose the commit list contains {1,2,3,4,6} and there are no active transactions. TID Prev TID Account# Balance 1 Null 10 100 3 1 10 200 1 Null 11 300 4 1 11 400 5 4 11 350 6 Null 12 500
  • 6. 3.A. What is the state of the table after running the following transaction?: TID=8: Increment the balance of account 10 by 100; Delete account 12; Insert account 13 with balance 700. The database state after transaction 8 commits TID Prev TID Account# Balance 1 Null 10 100 3 1 10 200 8 3 10 300 1 Null 11 300 4 1 11 400 5 4 11 350 6 Null 12 500 8 6 12 deleted 8 Null 13 700 TID Prev TID Account# Balance 1 Null 10 100 3 1 10 200 1 Null 11 300 4 1 11 400 5 4 11 350 6 Null 12 500
  • 7. 3.B. Suppose a read-only query with TID=7 reads all the accounts. It starts executing before executing transaction 8 starts executing and finishes after transaction 8 commits (same transaction 8 as part (a)). Which versions of which rows does it read?
  • 8. 3.B. • When it started executing, transaction 7 read the following commit list: {1,2,3,4,6}. • It read the following: • version TID 3 of Account 10, • version TID 4 of Account 11 (because 5 didn’t commit) • version TID 6 of account 12. • It does not see any of transaction 8’s updates because transaction 8 was not on the commit list when it started. TID Prev TID Account# Balance 1 Null 10 100 3 1 10 200 8 3 10 300 1 Null 11 300 4 1 11 400 5 4 11 350 6 Null 12 500 8 6 12 deleted 8 Null 13 700
  • 9. 3.C. After transactions 7 and 8 have finished and no other transactions are active, suppose we garbage collect all of the versions that aren’t needed. Assuming transaction ids increase monotonically with respect time, what does the table look like after the garbage collection step? The garbage collector keeps the last committed update of each account: TID Prev TID Account# Balance 8 Null 10 300 4 Null 11 400 8 Null 13 700 TID Prev TID Account# Balance 1 Null 10 100 3 1 10 200 8 3 10 300 1 Null 11 300 4 1 11 400 5 4 11 350 6 Null 12 500 8 6 12 deleted 8 Null 13 700
  • 10. Problem 4 Suppose file F contains a sequence of fixed-length records, and F’s descriptor includes a count of the number of records in F, which is used to find the end of F. Consider the following two transactions: • T1: • Scan F, returning all the records in F • Read(x) • T2: • Insert a record into F • Write(x) Data item x is not in F. Both transactions are two-phase locked (locking records in F and x), but neither transaction locks count.
  • 11. 4.A. Given an example of a non-serializable execution of T1 and T2. Explain why it’s non- serializable. 1. T1: Scan F, returning all the records in F 2. T2: Insert a record into F 3. T2: Write(x) 4. Commit2 5. T1: Read(x) • The first two operations imply and T1 precedes T2, but since they don’t lock count, the first operation doesn’t cause the second one to be delayed. • The third and fifth operations on x conflict, which imply that T2 precedes T1. • So the execution isn’t SR.
  • 12. 4.B. Explain why this is an example of the phantom problem. • T1: • Scan F, returning all the records in F • Read(x) • T2: • Insert a record into F • Write(x) T2’s insertion into F is a phantom record. T1’s scan doesn’t see the record, but T1’s Read(x) indirectly sees the result in data item x (assuming the value of x is a function of the records in F).