Rick, Charles, et others, Thank you for the quick answers. I have quickly tried your solutions and both the initial create with bigger hash and the change+resize on an existing file seem to work, I can now easily lock 20k records in one transaction.
I have yet to find out why we hit this issue on live servers in our application (so why the hash on the affected files is apparently so small. I will take a look at that Monday. For now I am quite happy because I have a solution for the immediate problem. Also I have been trying to SELECT 40k records after the write of 20k new ones and that worked also, I am very confused now because I have been "brought up" with the idea that there is no thing more disastrous then a SELECT in a Universe transaction (locking table problems all around I am told.) Is that something you have heard of? Or is it just another fable? Thanks again for the help, it is very much appreciated. Regards, Andre Meij Innovate-IT -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Saturday, March 10, 2007 7:04 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Dynamic files, big transactions Andre, I'm with Rick. He suggested "new partfile". But maybe some kind of queue or workfile, that routinely gets flushed, merging to modulo 1. And maybe zero length record or very small, so that 250 ids all land in the same group? Is group size 4KB? What does that have to do with the lock table in memory, you (or some lurker) may ask? When a record is locked, UV uses the inode & group# to determine where to plant the lock in the lock table. So that means that all these records will be assigned to the same lock group, since inode & group# (i.e., 1) will be the same for all. If you gave it a larger minimum.modulus, or converted that queue/work file to static, then, when you lock many or all records at once, that would spread the load across several lock groups, since the inode&group# combo would vary from record to record. cds P.S. I *think* splits and merges are suspended on groups that have records currently in the lock table. (Since group# determines where something is in the lock table, you couldn't have that being changed out from under you.) So as long as a record remains locked, your dynamic file will be not quite so dynamic. You might be hitting that, too. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
