[
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/1/10 5:57 PM:
---------------------------------------------------------------------
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!
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.
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.
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.
