Openbravo Issue Tracking System - Retail Modules
View Issue Details
0037666Retail ModulesStoreServerpublic2018-01-18 11:282018-01-29 16:23
AugustoMauch 
AugustoMauch 
normalmajorhave not tried
closedfixed 
5
 
 
mtaal
No
0037666: Error when creating an order: duplicate key value violates unique constraint "obstsyn_srvr_bp_uni"
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.

I have not been able to reproduce it locally, but I have been able to simulate using the attached patch.
When checking if a business partner belongs to a store, do not check only the database, but also check if the current session.
No tags attached.
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 
diff reproduceIssue37666.diff (879) 2018-01-18 11:29
https://issues.openbravo.com/file_download.php?file_id=11465&type=bug
Issue History
2018-01-18 11:28AugustoMauchNew Issue
2018-01-18 11:28AugustoMauchAssigned To => AugustoMauch
2018-01-18 11:28AugustoMauchTriggers an Emergency Pack => No
2018-01-18 11:29AugustoMauchFile Added: reproduceIssue37666.diff
2018-01-18 12:23hgbotCheckin
2018-01-18 12:23hgbotNote Added: 0101772
2018-01-18 12:23hgbotStatusnew => resolved
2018-01-18 12:23hgbotResolutionopen => fixed
2018-01-18 12:23hgbotFixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.storeserver.synchronization/rev/1909599e57cce5c20ac35ed38c6f3f6d8570153f [^]
2018-01-18 12:25AugustoMauchReview Assigned To => mtaal
2018-01-18 15:40ioritzCiaRelationship addedhas duplicate 0037671
2018-01-21 13:03mtaalNote Added: 0101811
2018-01-21 13:03mtaalStatusresolved => new
2018-01-21 13:03mtaalResolutionfixed => open
2018-01-21 13:04mtaalNote Edited: 0101811bug_revision_view_page.php?bugnote_id=0101811#r16566
2018-01-22 12:54hgbotCheckin
2018-01-22 12:54hgbotNote Added: 0101836
2018-01-22 12:54hgbotStatusnew => resolved
2018-01-22 12:54hgbotResolutionopen => fixed
2018-01-22 12:54hgbotFixed in SCM revisionhttp://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:23mtaalNote Added: 0102028
2018-01-29 16:23mtaalStatusresolved => closed
2018-02-21 14:34AugustoMauchRelationship addedrelated 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   
Repository: erp/pmods/org.openbravo.retail.storeserver.synchronization
Changeset: 255a7dc6d2ccf16a9395d7cb72fbb59251f76a64
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Mon Jan 22 12:53:31 2018 +0100
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.storeserver.synchronization/rev/255a7dc6d2ccf16a9395d7cb72fbb59251f76a64 [^]

Fixes issue 37666: Checks properly if two mobile servers are the same

Instead of using equals on the mobile servers themselves, they are compared by comparing their IDs.

---
M src/org/openbravo/retail/storeserver/synchronization/utils/BusinessPartnerSegmentationUtils.java
---
(0102028)
mtaal   
2018-01-29 16:23   
tested & reviewed