[
https://issues.apache.org/jira/browse/FINERACT-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Santa updated FINERACT-2000:
----------------------------------
Description:
Current Fineract behaviour:
* optimistic locking exception: 423 {{SC_LOCKED}}
the request was retried inside Fineract (configuration times) but was not
successful
** status: FAILED
** when: more than one thread is trying to modify the same entity concurrently
** caller: should retry with a NEW idempotency key
** ams connector: implemented retry configuration times
** issue: not ideal as 423 is a WebDav code
** suggested: change to return code to 409 {{SC_CONFLICT}}
* pessimistic locking: 409 {{SC_CONFLICT}}
the request was retried inside Fineract (different configuration times) but was
not successful
** status: not registered currently, should be FAILED
** when: the COB process is currently running and we try to modify the entity
only implemented on Loan so we will not have it on SavingsAccount
** caller: should retry with a NEW idempotency key
** ams connector: no retry, currently returns null
** issue: same code as process in progress, must be different - already on
prod, so finer act community should allow the change
** suggested: fix audit log and keep return code 409 {{SC_CONFLICT}}
* process in progress: 409 {{SC_CONFLICT}}
the request was already started by a different thread
** status: IN PROGRESS
** when: the process with same idempotency key was already started by a
different thread
specially for jobs (async requests), or for other processes if more than one
instance can send the same request simultaneously (probably can not happen)
** caller: should retry with the SAME idempotency key
** ams connector: no retry, currently returns null because we do not have
async requests, so another instance should return the correct response (success
or failed)
** issue: same code as pessimistic locking, must be different - already on
prod, so finer act community should allow the change
** suggested: change return code to 425 {{Too Early (RFC 8470), return null is
probably ok}}
* deadlock: 500 (not handled so maybe different)
deadlock is automatically retried but takes significant time so better to avoid
** status: FAILED
** when: example: two batches perform operation on the same entities but in
different order
** caller: should retry with a NEW idempotency key
** ams connector: not handled
** issue: implement or better to change the logic
one of the deadlock types we already fixed in the ams connector:
batch1: account1 operation, account2 operation; batch2: account2 operation,
account1 operation
was changed to
batch1: account1 operation, account2 operation; batch2: account1 operation,
account2 operation
we also encountered deadlock on Savings transactions which is not handled yet
** suggested: change Savings Transaction handling (core change) and handle
deadlock exception
change return code to 409 {{SC_CONFLICT}}
Batch failed requests are not saved currently in the audit lock, so calling
even the failed requests with the same idempotency key is working. Should be
fixed.
> Clean-up retryable error codes
> ------------------------------
>
> Key: FINERACT-2000
> URL: https://issues.apache.org/jira/browse/FINERACT-2000
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Performance, Savings
> Affects Versions: 1.9.0
> Reporter: Peter Santa
> Priority: Major
> Labels: BeanSalad
> Fix For: 1.9.0
>
>
> Current Fineract behaviour:
> * optimistic locking exception: 423 {{SC_LOCKED}}
> the request was retried inside Fineract (configuration times) but was not
> successful
> ** status: FAILED
> ** when: more than one thread is trying to modify the same entity
> concurrently
> ** caller: should retry with a NEW idempotency key
> ** ams connector: implemented retry configuration times
> ** issue: not ideal as 423 is a WebDav code
> ** suggested: change to return code to 409 {{SC_CONFLICT}}
> * pessimistic locking: 409 {{SC_CONFLICT}}
> the request was retried inside Fineract (different configuration times) but
> was not successful
> ** status: not registered currently, should be FAILED
> ** when: the COB process is currently running and we try to modify the entity
> only implemented on Loan so we will not have it on SavingsAccount
> ** caller: should retry with a NEW idempotency key
> ** ams connector: no retry, currently returns null
> ** issue: same code as process in progress, must be different - already on
> prod, so finer act community should allow the change
> ** suggested: fix audit log and keep return code 409 {{SC_CONFLICT}}
> * process in progress: 409 {{SC_CONFLICT}}
> the request was already started by a different thread
> ** status: IN PROGRESS
> ** when: the process with same idempotency key was already started by a
> different thread
> specially for jobs (async requests), or for other processes if more than one
> instance can send the same request simultaneously (probably can not happen)
> ** caller: should retry with the SAME idempotency key
> ** ams connector: no retry, currently returns null because we do not have
> async requests, so another instance should return the correct response
> (success or failed)
> ** issue: same code as pessimistic locking, must be different - already on
> prod, so finer act community should allow the change
> ** suggested: change return code to 425 {{Too Early (RFC 8470), return null
> is probably ok}}
> * deadlock: 500 (not handled so maybe different)
> deadlock is automatically retried but takes significant time so better to
> avoid
> ** status: FAILED
> ** when: example: two batches perform operation on the same entities but in
> different order
> ** caller: should retry with a NEW idempotency key
> ** ams connector: not handled
> ** issue: implement or better to change the logic
> one of the deadlock types we already fixed in the ams connector:
> batch1: account1 operation, account2 operation; batch2: account2 operation,
> account1 operation
> was changed to
> batch1: account1 operation, account2 operation; batch2: account1 operation,
> account2 operation
> we also encountered deadlock on Savings transactions which is not handled yet
> ** suggested: change Savings Transaction handling (core change) and handle
> deadlock exception
> change return code to 409 {{SC_CONFLICT}}
> Batch failed requests are not saved currently in the audit lock, so calling
> even the failed requests with the same idempotency key is working. Should be
> fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
