--- 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.
