From: Thompson, B. B. <BRY...@sa...> - 2006-02-21 16:49:24
|
All, Let's assume that jdbm uses locking for rw synchronization and MVCC for ww synchronization. This means that updated rows will NOT be updated in place. Instead a new version of the row will be created by logically appending the row to the store (either reusing a deleted physical row or using an empty page to lay down new physical rows). In the case of a VLR Tx, isolation of the new rows on unused pages will ensure that the DBCache policy of exclusive access to the VLR Tx pages does not conflict with the access of other transactions to pre-existing versions. This further suggests to me that we should buffer serialized rows so that (a) we can cluster them and (b) we can decide whether to use some rows from the deleted physical rows list or begin allocation on an unused page. If the buffer is not filled before the tx commits, then we can use some deleted physical rows since we know that the tx will not be promoted to VLR status. If the buffer is filled then the tx may be promoted to VLR status, so we would allocate on unused pages (one page at a time) to ensure that a conflict does not arise with the DBCache policy of exclusive access for a VLR Tx to pages which it logs and then forces to the DB. Does that make sense to everyone? -bryan -----Original Message----- From: Thompson, Bryan B. To: Thompson, Bryan B.; ''jdb...@li... ' ' Sent: 2/21/2006 10:15 AM Subject: RE: intention locking JPEG All, I have attached another JPEG in which I lay out a few thoughts on how MVCC might be used to support ww-synchronization in combination with the use of locking to support rw-synchronization. -bryan -----Original Message----- From: Thompson, Bryan B. To: 'jdb...@li... ' Sent: 2/21/2006 9:23 AM Subject: intention locking JPEG All, I've attached a diagram outlining some thoughts on an intention locking scheme based on [1]. This is notionally to support the rw synchronization problem as 1/2 of a combined locking + MVCC solution. The idea is that locking is used to "induce" a serialization ordering. The DAG support should allow cycles to be forced and provide incremental tools for identifying and breaking cycles. Allowing cycles let's transactions violate serializability and also let's us consider which transactions should be aborted, rather than just the tx whose lock request produced the deadlock. I've been collecting some references on fast incremental cycle detection for the DAG part. Thoughts? -bryan PS: Alex, can you "approve" this for the list -- it is oversize. [1] J.N. Gray, R.A. Lorie, G.R. Putzolu, I.L. Traiger. Granularity of Locks and Degrees of Consistency in a Shared Data Base. http://www.seas.upenn.edu/~zives/cis650/papers/granularity-locks.pdf <<locking1.JPG>> <<mvcc-1.JPG>> |
From: Alex B. <boi...@in...> - 2006-02-21 21:17:38
|
Thompson, Bryan B. wrote: >Let's assume that jdbm uses locking for rw synchronization and MVCC for >ww synchronization. > > I don't understand what you mean here. >This means that updated rows will NOT be updated in >place. Instead a new version of the row will be created by logically >appending the row to the store (either reusing a deleted physical row or >using an empty page to lay down new physical rows). > > Ok >In the case of a VLR Tx, isolation of the new rows on unused pages will >ensure that the DBCache policy of exclusive access to the VLR Tx pages >does not conflict with the access of other transactions to pre-existing >versions. > > You also need isolation of row mapping pages. >This further suggests to me that we should buffer serialized rows so >that (a) we can cluster them and (b) we can decide whether to use some >rows from the deleted physical rows list or begin allocation on an unused >page. If the buffer is not filled before the tx commits, then we can use >some deleted physical rows since we know that the tx will not be promoted >to VLR status. > Yes. Do keep in mind that you can only reuse physical rows if no transaction can ever reach them. This requires some additional housekeeping. >If the buffer is filled then the tx may be promoted to >VLR status, so we would allocate on unused pages (one page at a time) to >ensure that a conflict does not arise with the DBCache policy of exclusive >access for a VLR Tx to pages which it logs and then forces to the DB. > > When and how would you update the mapping pages? alex |