[
https://issues.apache.org/jira/browse/FINERACT-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy closed FINERACT-859.
-------------------------------
Resolution: Abandoned
> Optimistic locking errors were detected when flushing to the data store
> -----------------------------------------------------------------------
>
> Key: FINERACT-859
> URL: https://issues.apache.org/jira/browse/FINERACT-859
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Michael Vorburger
> Priority: Major
>
> The integration test logs sometimes show:
> {{Optimistic locking errors were detected when flushing to the data store.
> The following objects may have been concurrently modified in another
> transaction: ...}}
> FINERACT-857 has one (of many, this happens fairly regularly..) example logs
> of this happening. (FINERACT-858 will make the real root cause more clearly
> stand out in future logs.)
> I think we need to catch and handle this problem with explicit retries in the
> code. Perhaps we can draw inspiration from related work I've done in a
> previous life, from this code:
> *
> https://github.com/opendaylight/genius/blob/master/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/infra/RetryingManagedNewTransactionRunnerImpl.java
> *
> https://github.com/opendaylight/genius/blob/master/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/infra/RetryingManagedNewTransactionRunner.java#L38
> * NOT
> https://github.com/opendaylight/genius/blob/master/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/datastoreutils/TaskRetryLooper.java
> BTW: This locking issue is probably (but I'm not 100% sure..) completely
> unrelated to the other one tracked in FINERACT-856.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
