Re: Row and Byte locks

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. -- -- Jake (Never yelled "CROWDED THEATER!" during a fire) +------------------------------------------------------------+ | The expedient performance of a task with excessive concern | | regarding its duration-to-completion engenders a virtual | | certainty of diminished benefit therefrom. | | -- Benjamin Franklin (but he said it in 3 words) | +------------------------------------------------------------+