It would be nice if it were that easy, but not only could there be multiple threads in a single app server instance but there could be multiple app servers using this at the same time.
This sounds like a transaction isolation problem, and really database transaction isolation is the only way to properly handle this. The place to look for this problem in a production system is what the database tx isolation is set to, and check if it is handling this right. Without handling it through the db the best option would be to write recovery code, ie call the save invoice in its own transaction and if it returns an error (and rolls back as part of that) then increment the ID (as James is doing manually) and try again. -David On May 19, 2010, at 4:42 PM, Adrian Crum wrote: > That looks like a bad design. There is no synchronization, so multiple > threads can create invoices with the same number. > > I would recommend creating a Jira issue. > > -Adrian > > On 5/19/2010 3:30 PM, James McGill wrote: >> This happened again, this time with an InvoiceId. >> >> What could possibly cause an Invoice to be written with an InvoiceId >> (received via, InvoiceServices.xml#getNextInvoiceId) >> without getNextInvoiceId writing the incremented value to >> PartyAcctgPreference ? >> >> In my log I can see the last time an InvoiceId was created. >> getNextInvoiceId logs its context, and the method succeeds (We are using >> INVSQ_ENF_SEQ etc.). The invoice is created and everything seems fine. >> >> Then the next and subsequent invoices fail because the PartyAcctgPreference >> wasn't updated. I can't understand from the code how that is even possible. >> >> Could<store-value value-field="partyAcctgPreference"/> >> possibly not be writing, but also not throwing an error? >>
