[ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917049#action_12917049 ]
Aleksey Fedorchenko edited comment on OFBIZ-3557 at 10/2/10 1:45 AM: --------------------------------------------------------------------- Hi! I've attached another kind of a fix of the problem above. It is a OFBIZ-3557-2.patch but let me describe the problem first. On the production system we're meeting this problem periodically: either invoice or order identifiers kept by the PartyAcctgPreference loose their integrity from time to time and are starting to generate duplicated values that violate the database constraints and prevent from the creation of invoices and orders. OFBIZ-3557-1.patch have not provided any feasible solution to our problem except for the fact that it pointed us to the problematic code there in the OFBiz core and was a great example of the way minilang may be extended. Thanks to Adrian Crum! The problem we have in the system may be described as a heavy access to the PartyAcctgPreference from the concurrent requests that are creating both orders and invoices simultaneously for the same party. In this case we need to serialize not only the getNextInvoiceId / getNextOrderId / getNextQuoteId separately but rather provide a synchronous access to the group of those operations to avoid concurrent update of a different counter fields of the same entity. In this perspective we're extending the "synchronized" attribute from OFBIZ-3557-1.patch with the "synchronized-lock-name" attribute that is a name of a mutex object being applied to a group of different operations. Another finding was in the field of the transaction scope getNextInvoiceId / getNextOrderId / getNextQuoteId operations are working in: they belong to the same transaction as the service of invoice / order / quote creation which would be considered as a wrong behavior for the multi-tasking environments. We introduced an atomic transaction scope for the getNextInvoiceId / getNextOrderId / getNextQuoteId operations that is basically suspending / resuming outer transaction to generate and store in the database an incremental identifier regardless of the possible failure of the outer business transaction. Please note that the OFBIZ-3557-2.patch might be considered as a replacement of OFBIZ-3557-1.patch and it provides changes against the 09.04 release source code. Please note as well that it is suitable for the single instance setups only. No clustering support was provided. Let me have your comments. Thanks! was (Author: lelik): Hi! On the production system we're meeting this problem periodically: either invoice or order identifiers kept by the PartyAcctgPreference loose their integrity from time to time and are starting to generate duplicated values that violate the database constraints and prevent from the creation of invoices and orders. OFBIZ-3557-1.patch have not provided any feasible solution to our problem except for the fact that it pointed us to the problematic code there in the OFBiz core and was a great example of the way minilang may be extended. Thanks to Adrian Crum! The problem we have in the system may be described as a heavy access to the PartyAcctgPreference from the concurrent requests that are creating both orders and invoices simultaneously for the same party. In this case we need to serialize not only the getNextInvoiceId / getNextOrderId / getNextQuoteId separately but rather provide a synchronous access to the group of those operations to avoid concurrent update of a different counter fields of the same entity. In this perspective we're extending the "synchronized" attribute from OFBIZ-3557-1.patch with the "synchronized-lock-name" attribute that is a name of a mutex object being applied to a group of different operations. Another finding was in the field of the transaction scope getNextInvoiceId / getNextOrderId / getNextQuoteId operations are working in: they belong to the same transaction as the service of invoice / order / quote creation which would be considered as a wrong behavior for the multi-tasking environments. We introduced an atomic transaction scope for the getNextInvoiceId / getNextOrderId / getNextQuoteId operations that is basically suspending / resuming outer transaction to generate and store in the database an incremental identifier regardless of the possible failure of the outer business transaction. Please note that the OFBIZ-3557-2.patch might be considered as a replacement of OFBIZ-3557-1.patch and it provides changes against the 09.04 release source code. Please note as well that it is suitable for the single instance setups only. No clustering support was provided. Let me have your comments. Thanks! > 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, OFBIZ-3557-2.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.