Openbravo Issue Tracking System - Retail Modules |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0037666 | Retail Modules | StoreServer | public | 2018-01-18 11:28 | 2018-01-29 16:23 |
|
Reporter | AugustoMauch | |
Assigned To | AugustoMauch | |
Priority | normal | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | |
Platform | | OS | 5 | OS Version | |
Product Version | | |
Target Version | | Fixed in Version | | |
Merge Request Status | |
Review Assigned To | mtaal |
OBNetwork customer | |
Support ticket | |
Regression level | |
Regression date | |
Regression introduced in release | |
Regression introduced by commit | |
Triggers an Emergency Pack | No |
|
Summary | 0037666: Error when creating an order: duplicate key value violates unique constraint "obstsyn_srvr_bp_uni" |
Description | The following error has been found in BUT logs:
cdb72c84 2017-10-30 10:48:11,586 [ajp-bio-127.0.0.1-8009-exec-1] ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: duplicate key value violates unique constraint "obstsyn_srvr_bp_uni"
Detail: Key (obmobc_server_definition_id, c_bpartner_id)=(30A6E1C1B9864EE5A5788FB92C958273, 00000000000000EEEEE0110000050874) already exists.
This may happen when a record is added to the OBSTSYN_Server_BPartner. This inserts are done when a business partner is included in an order for an organization where he does not belong to yet.
I have not been able to reproduce it locally but the problem is clear: two insertions for the same c_bpartner_id - obmobc_server_definition_id values are being done in the same transaction.
|
Steps To Reproduce | I have not been able to reproduce it locally, but I have been able to simulate using the attached patch. |
Proposed Solution | When checking if a business partner belongs to a store, do not check only the database, but also check if the current session. |
Additional Information | |
Tags | No tags attached. |
Relationships | has duplicate | defect | 0037671 | | closed | StoreServer | Unique constraint violation when doing a layaway with a customer from another store | related to | defect | 0037731 | | closed | AugustoMauch | obstsyn_srvr_bp_uni constraint is sometimes violated when synchronizing a business partner from a store to the central server |
|
Attached Files | reproduceIssue37666.diff (879) 2018-01-18 11:29 https://issues.openbravo.com/file_download.php?file_id=11465&type=bug |
|
Issue History |
Date Modified | Username | Field | Change |
2018-01-18 11:28 | AugustoMauch | New Issue | |
2018-01-18 11:28 | AugustoMauch | Assigned To | => AugustoMauch |
2018-01-18 11:28 | AugustoMauch | Triggers an Emergency Pack | => No |
2018-01-18 11:29 | AugustoMauch | File Added: reproduceIssue37666.diff | |
2018-01-18 12:23 | hgbot | Checkin | |
2018-01-18 12:23 | hgbot | Note Added: 0101772 | |
2018-01-18 12:23 | hgbot | Status | new => resolved |
2018-01-18 12:23 | hgbot | Resolution | open => fixed |
2018-01-18 12:23 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.retail.storeserver.synchronization/rev/1909599e57cce5c20ac35ed38c6f3f6d8570153f [^] |
2018-01-18 12:25 | AugustoMauch | Review Assigned To | => mtaal |
2018-01-18 15:40 | ioritzCia | Relationship added | has duplicate 0037671 |
2018-01-21 13:03 | mtaal | Note Added: 0101811 | |
2018-01-21 13:03 | mtaal | Status | resolved => new |
2018-01-21 13:03 | mtaal | Resolution | fixed => open |
2018-01-21 13:04 | mtaal | Note Edited: 0101811 | bug_revision_view_page.php?bugnote_id=0101811#r16566 |
2018-01-22 12:54 | hgbot | Checkin | |
2018-01-22 12:54 | hgbot | Note Added: 0101836 | |
2018-01-22 12:54 | hgbot | Status | new => resolved |
2018-01-22 12:54 | hgbot | Resolution | open => fixed |
2018-01-22 12:54 | hgbot | Fixed in SCM revision | http://code.openbravo.com/erp/pmods/org.openbravo.retail.storeserver.synchronization/rev/1909599e57cce5c20ac35ed38c6f3f6d8570153f [^] => http://code.openbravo.com/erp/pmods/org.openbravo.retail.storeserver.synchronization/rev/255a7dc6d2ccf16a9395d7cb72fbb59251f76a64 [^] |
2018-01-29 16:23 | mtaal | Note Added: 0102028 | |
2018-01-29 16:23 | mtaal | Status | resolved => closed |
2018-02-21 14:34 | AugustoMauch | Relationship added | related to 0037731 |
Notes |
|
(0101772)
|
hgbot
|
2018-01-18 12:23
|
|
Repository: erp/pmods/org.openbravo.retail.storeserver.synchronization
Changeset: 1909599e57cce5c20ac35ed38c6f3f6d8570153f
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Thu Jan 18 12:22:49 2018 +0100
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.storeserver.synchronization/rev/1909599e57cce5c20ac35ed38c6f3f6d8570153f [^]
Fixes issue 37666: Prevents violating obstsyn_srvr_bp_uni constraint
The problem was that two records for the same c_bpartner_id - obmobc_server_definition_id were being added to the OBSTSYN_Server_BPartner in a single transaction.
This happened because the to check if a record existed for those values, only the values from the database were verified. If the insert had been done in the DAL session but not commited, they would not be found, so the records would be saved again, and the obstsyn_srvr_bp_uni constraint would be violated.
To fix this, instead of using an OBCriteria to go to the database to check if the record exists, the businessPartner.getOBSTSYNServerBPartnerList() is invoked to fetch the records. This will retrieve also the records added in the current session, because now instead of calling OBDal.getInstanace.save on the new records, it is added directly to businessPartner.getOBSTSYNServerBPartnerList().
---
M src/org/openbravo/retail/storeserver/synchronization/utils/BusinessPartnerSegmentationUtils.java
---
|
|
|
(0101811)
|
mtaal
|
2018-01-21 13:03
(edited on: 2018-01-21 13:04) |
|
Review node:
maybe by doing flush the updated list would have been saved to the db before the criteria is executed. But doing flush has side effects also, so better to minimize that.
My first thought was that loading the bp-server-list like this would be heavy, but it is loaded anyway most of the time by following logic in callers.
My main remark (to re-open the issue also) is that doing equals on objects from hibernate can be somewhat tricky as the passed mobileserver may have been read in a different session. Therefore better I think to compare ids. If the dal utils getId method is used this also saved some small db queries.
|
|
|
(0101836)
|
hgbot
|
2018-01-22 12:54
|
|
|
|
(0102028)
|
mtaal
|
2018-01-29 16:23
|
|
|