[jira] [Commented] (OFBIZ-3910) Sending multiple emails simultaneously to new party does not work properly

["Anil K Patel (Jira)" <ji...@apache.org>]

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

Anil K Patel commented on OFBIZ-3910:
-------------------------------------

Confirmed still reproducible in current trunk — and verified empirically, not just by code inspection.

*Reproduction:* a throwaway concurrency test fired 20 simultaneous ensurePartyRole(partyId, roleTypeId=ADDRESSEE) calls at a single brand-new party. Result: 7 succeeded, 13 failed, exactly 1 PartyRole row persisted. The 13 failures were all the original error:
Unique index or primary key violation ... OFBIZ.PARTY_ROLE(PARTY_ID, ROLE_TYPE_ID) — i.e. the same pk_party_role duplicate-key violation reported in 2010 (reporter was on PostgreSQL; reproduced here on H2 — same constraint, same race).

*Mechanism:* ensurePartyRole -> ensureNaPartyRole (PartySimpleMethods.xml) does find-by-primary-key on PartyRole (with use-cache="true") and then create-value only if absent — a check-then-create with no concurrency guard. Under concurrency several callers see the row absent and all attempt the INSERT; the DB unique constraint rejects the losers and rolls back their transaction. The earlier partial fix (commit d4ca029003, 2009) added the same check-before-create idiom and so does not help the concurrent case.

*Two distinct defects, and the second is the costly one:*
1. The duplicate-key race above — the trigger.
2. In the email flow this failure occurs after messages have already been handed to the SMTP server. The rollback makes OFBiz treat the send as failed and retry it, so recipients receive the email twice. A fix that only makes PartyRole creation idempotent removes the trigger but leaves the "sent, then rolled back, then resent" hazard for any other post-send failure.

*Suggested direction:* (a) make addressee-role creation tolerant of a concurrent insert (treat duplicate-key as success rather than rolling back); and (b) ensure that once messages are physically sent, downstream bookkeeping failures cannot cause a resend. Leaving this open as a confirmed concurrency / data-integrity bug.

> Sending multiple emails simultaneously to new party does not work properly
> --------------------------------------------------------------------------
>
>                 Key: OFBIZ-3910
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-3910
>             Project: OFBiz
>          Issue Type: Bug
>          Components: party
>    Affects Versions: Release Branch 10.04
>            Reporter: Martin Kreidenweis
>            Priority: Major
>
> Sending more than one email at once to a party that never has received an email using the sendMailFromScreen service fails. 
> Creating the communication event for the email in this case triggers the createPartyRole service. So two threads apparently try to insert the same party role. This results in the following error: 
> {code}
> java.lang.Exception: Failure in create operation for entity [PartyRole]: org.ofbiz.entity.GenericEntityException: Error while inserting: [GenericEntity:PartyRole][createdStamp,2010-08-30 10:44:41.144(java.sql.Timestamp)][createdTxStamp,2010-08-30 10:44:26.709(java.sql.Timestamp)][lastUpdatedStamp,2010-08-30 10:44:41.144(java.sql.Timestamp)][lastUpdatedTxStamp,2010-08-30 10:44:26.709(java.sql.Timestamp)][partyId,RegisteredMerchantCompany(java.lang.String)][roleTypeId,ADDRESSEE(java.lang.String)] (SQL Exception while executing the following:INSERT INTO ofbiz.PARTY_ROLE (PARTY_ID, ROLE_TYPE_ID, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?) (ERROR: duplicate key value violates unique constraint »pk_party_role«)). Rolling back transaction.
> {code}
> This happens only after the actual emails are sent. OFBiz now rolls back the transaction, thinks the email sending failed, and tries to send the emails again later. 
> Workaround: 
> Create a PartyRole ADDRESSE for the party before trying to send emails. 
> We did not find a good solution for the actual problem. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)