[jira] Created: (OFBIZ-3557) Enforced sequence does not work with concurrent access

[Nicolas Malin (Jira)]

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 9.04, SVN trunk
            Reporter: Wickersheimer Jeremy


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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846500#action_12846500 ]

Wickersheimer Jeremy commented on OFBIZ-3557:
---------------------------------------------

While looking for a possible solution using SemaphoreService, i noticed that the semaphore / semaphoreWait / semaphoreSleep attributes are not copied in the ModelService clone constructor.
The result is that they are never used.

This happens in trunk and 09.04, i do not attach a patch all that is needed in ModelService is to add:

        this.semaphore = model.semaphore;
        this.semaphoreWait = model.semaphoreWait;
        this.semaphoreSleep = model.semaphoreSleep;

in the clone constructor.

Then i think we can work around this JIRA issue by marking the storeOrder service (for example) to use the semaphores.

> 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 9.04, SVN trunk
>            Reporter: Wickersheimer Jeremy
>
> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846554#action_12846554 ]

Jacques Le Roux commented on OFBIZ-3557:
----------------------------------------

Thanks Jeremy,

Hopefully, Adam who assigned 2353  to himself and marked this one as a duplicate will apply your solution or has already another one, Adam?

> 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 9.04, SVN trunk
>            Reporter: Wickersheimer Jeremy
>
> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846573#action_12846573 ]

Wickersheimer Jeremy commented on OFBIZ-3557:
---------------------------------------------

The above fix is not relative to sequence issues. But i've been able to use the semaphore locking on storeOrder for example which actually fixes the problem of ID collisions.

Obviously this is not a clean solution, because it involves changing the service definition to use the semaphore for people who use strict sequencing.

I guess the real solution could be in between, but i am not sure how it should be implemented. The getNextOrderId service should do the locking inside the simple method and only if the strict sequencing is used. And then the lock should be kept until the transaction is committed, and not just until the end of the service.

> 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 9.04, SVN trunk
>            Reporter: Wickersheimer Jeremy
>
> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846599#action_12846599 ]

Jacques Le Roux commented on OFBIZ-3557:
----------------------------------------

Thanks for comment Jeremy,

I will sleep on that...

> 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 9.04, SVN trunk
>            Reporter: Wickersheimer Jeremy
>
> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869392#action_12869392 ]

Adrian Crum commented on OFBIZ-3557:
------------------------------------

Another solution would be to have a separate entity for just the party ID and the invoice number. The primary key includes both fields. Then you can guarantee a unique invoice number this way:

1. Get current value
2. Add increment
3. Store new value
4. If an exception is thrown, go to step 2

> 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
>
> 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.

[Nicolas Malin (Jira)]

     [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Crum updated OFBIZ-3557:
-------------------------------

    Attachment: OFBIZ-3557-1.patch

OFBIZ-3557-1.patch fixes PART of the problem. It adds synchronization capability to simple methods, and the problematic methods are flagged as synchronized.

This should fix the duplicate ID problem in a single-server environment. Multi-server setups will require a completely different ID generation algorithm.

> 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870058#action_12870058 ]

Adrian Crum commented on OFBIZ-3557:
------------------------------------

By the way, this issue is NOT a duplicate of OFBIZ-2353. The problem described here is not due to any alleged flaws in SequenceUtil.

> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870166#action_12870166 ]

Scott Gray commented on OFBIZ-3557:
-----------------------------------

http://svn.ofbiz.org/viewcvs
that's the viewvc link for the old repo

About the lack of synchronization, shouldn't be possible to issue a lock on the row retrieved from PartyAcctgPreference so that no other transactions can read from it until the current one is committed?

> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870237#action_12870237 ]

Adrian Crum commented on OFBIZ-3557:
------------------------------------

I'm not sure record locking is needed. I suggested a solution that I think will work - the generated IDs are kept in an entity where they are part of the primary key, and you write a loop to keep trying incremental ID values until a store is successful. Plus, the code needs to be rewritten so the ID generation and invoice/order generation are atomic - they both succeed or they both fail.

> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870372#action_12870372 ]

BJ Freeman commented on OFBIZ-3557:
-----------------------------------

I have not gone through all 15 to see if they are specific to getNextInvoiceId
but they have  getNextInvoiceId   in them
 r558532  this one was 7/27/2007
r646697
r667748
r684546
r730092 [1/3]  and a bunch righ after.

> 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.

[Nicolas Malin (Jira)]

     [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Fedorchenko updated OFBIZ-3557:
---------------------------------------

    Attachment: OFBIZ-3557-2.patch

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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917198#action_12917198 ]

Adrian Crum commented on OFBIZ-3557:
------------------------------------

Aleksey,

Instead of a named lock, couldn't you call the individual ID generation methods from a single method and then synchronize that method? It seems to me it would have the same effect as a named lock.

> 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917533#action_12917533 ]

Aleksey Fedorchenko commented on OFBIZ-3557:
--------------------------------------------

Adrian,

It seems I have not understand your vision properly, sorry. As for me, it is not possible as those getNextXXXId methods located in the different services, they have different body and they are in use in different locations over the system (I found no intersections in the tree of dependencies from those methods). From my standpoint my fix is the only quick-n-dirty solution for the problem. At least, our production servers are telling me about this -- problem has gone.

Could you please set me an example implementation of your idea? Even the pseudo code would be acceptable in this case.

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.