Re: Row and Byte locks

In article <348C88AD.12EE04C5@garpac.com>, Jacob Salomon <jake@garpac.com> writes >S.Sathish wrote: > >> if >> row lock - a lock placed on a single data row >> Byte lock - a lock placed on a row containing varchars >> Then, What does " The byte lock will only lock the portion of the >> row that is being modified " mean? > >These explanations in the course manual as well as in the admin guide >are masterpieces of doubletalk IMO. > >Here's how I had it explained to me: > >Scenario without byte locks: > >I have a table with varchar columns. The maximum length of the row is >700 bytes. > >A row currently occupies 500 bytes. Its page has 650 bytes available >(effectively full with respect to varchar rows) > >I update that row in a transaction and it is now only 400 bytes. To all >appearences, the page now has 750 bytes available. In fact, the free >byte count in the page header indicates this. Probably, so does the the >bitmap entry for this page. > >User yutz inserts a 700-byte row into the page, leaving 50 bytes free in >the page. > >I decide to roll back my update, raising the row length from 400 bytes >back to 500 bytes. > >BZZZZZTTTT!!!! I can't roll back because there's no space in the page >to restore the full 100 lost bytes from the row. > >Scenario with byte locks: > >I have a table with varchar columns. The maximum length of the row is >700 bytes. > >A row currently occupies 500 bytes. Its page has 650 bytes available >(effectively full with respect to varchar rows) > >I update that row in a transaction and it is now only 400 bytes. To all >appearences, the page now would have 750 bytes available. However, my >update also places a 100-byte byte-lock on the page, telling all other >users: Whatever y'all do on this here page, you MUST leave 100 bytes for >me to roll back into. BTW, the "free byte count" in the page header >still says 750 free bytes and the bitmap entry for the page says the >page has room for a row. > >User yutz searches for a page to insert that 700-byte row. Finds this >page available based on the bitmap and free-byte count. However, because >there is a 100-byte byte lock, yutz's thread realizes that only 650 >bytes in the page are really free & clear. > >Yutz's thread continues to look for another page. > >That was the logical, reasonable explanation. > >However... > >A few days after getting that explantion, when I had some time on my >hands, I actually put this to the test with a very small OnLine 5.0x >system and varchar rows. > >What actually happened was that the yutz insert reduced the size of the >byte lock, making a rollback on this page impossible. The rollback >succeeded anyway, apparently onto another page (with forwarding >pointer). > >My next expriment was to fill the entire dbspace so that there was no >room in the dbspace for the restored row plus the new row. The dbspace >suddenly experienced an error and got marked irretrievably down. > >I did post mail at the time, requesting an explanation for why the yutz >update worked in the first place. The responses I got sounded like the >artful doubletalk of the manuals. > >And I had too much real work to really pursue this at the time. > >So if someone can respond to my $.02, the knowlege would be beneficial >to all the C.D.I. family. I'll play with Online at work tomorrow.... -- David Williams