[
https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870042#action_12870042
]
Adrian Crum commented on OFBIZ-3557:
------------------------------------
Here is some more information that might help anyone wanting to tackle this
problem.
Originally, OFBiz followed this pattern for generating invoices/orders:
1. Begin transaction
2. Create a new value
3. Get an ID from SequenceUtil
4. Store the ID in the new value
5. Store the new value
6. Commit transaction
The process was atomic and reliable. SequenceUtil would guarantee a unique ID.
The entity receiving the ID had the ID in the primary key, so even in the
unlikely event SequenceUtil produced a duplicate ID, the store operation would
fail because of a duplicate key violation.
Somewhere along the way this process was changed (I can't find out where
because it was before OFBiz joined the ASF). If an OFBiz instance is set up for
sequential invoice/order IDs, this pattern is used for generating
invoices/orders:
1. Begin transaction
2. Create a new value
3. Get an ID from the getNextInvoiceId service:
4. Begin transaction
5. Get last invoice/order number from PartyAcctgPreference
6. Increment number
7. Store new number in PartyAcctgPreference
8. Commit transaction
9. Store the ID in the new value
10. Store the new value
11. Commit transaction
The getNextInvoiceId service is in a simple method. Simple methods are not
synchronized.
This new pattern is a bad design. It is not atomic and the generated IDs are
not guaranteed to be unique. Not only is this pattern likely to fail, it is
*guaranteed* to fail. The whole thing needs to be redesigned.
In the meantime, the patch I provided fixes the getNextInvoiceId service by
making the simple method synchronized. It should help in single-server setups.
There is still a possibility that a valid ID will be generated, but the
invoice/order creation will fail (since the two operations are in separate
transactions). The end result from the user's perspective is that there will be
random gaps in invoice/order IDs.
> Enforced sequence does not work with concurrent access
> ------------------------------------------------------
>
> Key: OFBIZ-3557
> URL: https://issues.apache.org/jira/browse/OFBIZ-3557
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 09.04, SVN trunk
> Reporter: Wickersheimer Jeremy
> Attachments: OFBIZ-3557-1.patch
>
>
> There is a fundamental issue with enforced sequences (for orders, invoices,
> etc ..) and concurrency.
> For example if two users are creating an order at the same time one of them
> will see the creation fail with a PK error. The problem is that the
> "getNextXXXId" rely on the party accounting preference entity, but there is
> absolutely no guarantee that the last number in the sequence gets updated
> before another service can read it.
> This is at best very annoying when used only internally but may be
> unpractical for e-commerce sites.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
