Matt, If you follow the thread from the start and visit the Jira issue, you will see that we are discussing a very specific problem - not transactions or sequences in general.
To summarize: There is code in OFBiz that generates sequential ID numbers for orders and invoices. That code does not follow the established pattern for generating sequences, and as a result it will produce non-sequential IDs. A Jira issue has been created and we are working on the problem. -Adrian --- On Thu, 5/20/10, Matt Warnock <[email protected]> wrote: > From: Matt Warnock <[email protected]> > Subject: Re: QuoteId and OrderId sequence, possible race condition? > To: [email protected] > Date: Thursday, May 20, 2010, 5:15 PM > 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 > > > > >
