Adrian Crum wrote: > --- On Sat, 3/13/10, Adam Heath <[email protected]> wrote: >> Adrian Crum wrote: >>> --- On Fri, 3/12/10, Adrian Crum <[email protected]> >> wrote: >>>> Consistent random foreign key violations. Two >> records would >>>> get the same sequence number. Random in that >> different >>>> entities would be affected each time, and >> consistent in that >>>> it happens nearly every time. >>>> >>>> Try running five or more threads against it on a >>>> multi-processor machine. >>> Oops, maybe those were primary key violations. Bottom >> line is, an exception was thrown because two records got the >> same sequence ID. >> >> I've created a test case that runs 100 threads, all trying >> to get 1000 >> sequence values. I then verify that I get 100,0000 >> different values, >> and everything passes. >> >> Could it be that your multi-threaded wrapper ends up using >> different >> random delegators? This would say that the locking >> issues lie in the >> retry loop, which isn't being run by my multi-threaded >> code, since the >> bank in each thread is the same, and synchronized handles >> that >> concurrency. > > I modified the demo data loading code to make it multi-threaded, so I believe > only one delegator is being used. I have the patch at work, so I can't take a > look at it until Monday.
Heh. I run screen, so when I go home, I can just connect back to work, and have everything immediately available. All remote machines I connect to I immediately install screen. So, when I have to continue client work from home, I can also resume wherever I was last at. My laptop at home has been logged in to work since Feb. 21, without disconnecting. Could it be the sub sequence logic that is broken?
