Re: Key-Value locking with RR (was Re: Does Informix do Versioning ...)

Graeme Sargent <graeme@pyramid.com> wrote: :I guess I was thrown a bit by the data getting inserted into a new page, :when I didn't think it should be. I've just rerun my tests and this :didn't happen again. : :I think this can be explained as follows: : : I forgot to change the table to row level locking before I : started. Well, that will certainly make a difference ;-) : I think I must have attempted an insert before I noticed the : omission. : I think that must have updated an "insert next row" pointer in : the tablespace header in shmem. : All subsequent inserts got pointed at the new page instead of : the partially full page. : Tablespace was reopened causing the shmem pointer to revert to the : partially full page. To tell the truth, I've never really looked at how OnLine decides which page to put new rows on. I don't know if there's an "insert next row" pointer in the tablespace header. It makes sense to me that, if page x, the only partially full datapage, is locked, it picks page y, an empty page, to receive new rows; and having done that, it would keep using page y until either it is full, or until an insert finds page y locked. But while you were trying to insert other new rows, did you keep page x locked, or did you free it, and see new inserts still going to page y? Obviously, if x stayed locked, new inserts will have to go to y. June ---- June Tong Informix Asia/Pacific ---- ---- On-Loan Engineer Singapore ---- ---- junet@informix.com (65) 298-1716 ----