Isn't this exactly the kind of thing that SQL transactions, sequences, and foreign key constraints are designed to solve?
If the thread is using transactions properly, the whole transaction should either be rolled back, or completed. Either way, the database SHOULD be in a wholly consistent state. But it obviously isn't. So either we are doing something outside a transaction, that really should be done INSIDE a transaction, or the database has a seriously flawed implementation of transactions. -- Matt Warnock <[email protected]> RidgeCrest Herbals, Inc. On Thu, 2010-05-20 at 12:43 -0700, Adrian Crum wrote: > I doubt there will be any need for additional synchronization. > > I think I know what's going on in your system. My previous scenario > wasn't correct because I thought the ID was a part of the primary key > and there was an exception thrown while storing the new value - due to a > duplicate key violation. Those IDs are not a part of the primary key, so > that isn't the cause. > > Instead, I believe the ID is updated successfully, but a thread is slow > in storing the new ID value - which ends up decrementing the ID in the > database instead of incrementing it. Then the invoice generation fails > due to a duplicate key violation. From that point on, every attempt to > increment the ID value and create a new invoice with it will fail > because the new ID value already exists in the invoice file. > > -Adrian > > On 5/20/2010 11:57 AM, James McGill wrote: > > On Thu, May 20, 2010 at 10:46 AM, Adrian Crum<[email protected]> wrote: > > > >> James, > >> > >> I uploaded a patch that might fix your problem: > >> > >> > > Thanks Adrian. Your approach adds JVM-based synchronization to minilang > > simple methods. > > > > I still wonder if this means the create services need to be synchronized and > > not just the id generators. > > > > I'll try it out and keep you posted. > > > > > > James > >
