> > The service opens a transaction. The first thing it does is call > > createInvoice The service opens a transaction. The first thing it does is > > call > > > createInvoiceId. createInvoiceId also opens a transaction. It looks up > > > PartyAcctgPreference for "AA". It checks INVSQ_ENF_SEQ. Seeing "true", > > > it > > > then reads lastInvoiceNumber, increments it by one, writes it back to the > > > Entity, returns this value to createInvoice, committing its transaction. > > > createInvoiceId writes the Invoice and commits its transaction. > > > Everything > > > is fine in a single thread, of course. > > Id. createInvoiceId also opens a transaction. It looks up > > PartyAcctgPreference for "AA". It checks INVSQ_ENF_SEQ. Seeing "true", it > > then reads lastInvoiceNumber, increments it by one, writes it back to the > > Entity, returns this value to createInvoice, committing its transaction. > > createInvoiceId writes the Invoice and commits its transaction. Everything > > is fine in a single thread, of course.
Sounds like there are actually 3 nested transactions here. Big problem for MySQL. For the short run, I would probably try refactoring the createInvoiceID into the createInvoice code, and see if I could turn off the outermost enclosing service transaction. You could also test it with PostgreSQL or something that at least purports to support nested transactions, but I'd still not trust nested transactions, if I were writing the code. Wish I could be more help, but I don't know minilang and ofbiz like SQL, yet. -- Matt Warnock <[email protected]> RidgeCrest Herbals, Inc.
