Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0037666 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [Retail Modules] StoreServer | major | have not tried | 2018-01-18 11:28 | 2018-01-29 16:23 | |||
Reporter | AugustoMauch | View Status | public | |||||
Assigned To | AugustoMauch | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | 255a7dc6d2cc | ||||
Projection | none | ETA | none | Target Version | ||||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Review Assigned To | mtaal | |||||||
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. | |||||||
Tags | No tags attached. | |||||||
Attached Files | reproduceIssue37666.diff [^] (879 bytes) 2018-01-18 11:29 [Show Content] | |||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |||||||||||||||
|
Notes | |
(0101772) hgbot (developer) 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 (manager) 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 (developer) 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 (manager) 2018-01-29 16:23 |
tested & reviewed |
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 | View Revisions |
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 |
Copyright © 2000 - 2009 MantisBT Group |