You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Michael Vorburger (Jira)" <ji...@apache.org> on 2020/03/08 21:28:00 UTC
[jira] [Updated] (FINERACT-856) Deadlock found when trying to get
lock try restarting transaction
[ https://issues.apache.org/jira/browse/FINERACT-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Vorburger updated FINERACT-856:
---------------------------------------
Description:
The integration test logs sometimes show:
{{Deadlock found when trying to get lock try restarting transaction}}
I'm not clear whether those are log messages that can be ignored, because there is retry logic in place (e.g. in/by OpenJPA?), or if this indicates real failures which we must handle with a retry logic in the code... some background:
* https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlocks.html
* https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlock-example.html
* https://stackoverflow.com/questions/2332768/how-to-avoid-mysql-deadlock-found-when-trying-to-get-lock-try-restarting-trans
* https://stackoverflow.com/questions/17747906/getting-deadlock-found-when-trying-to-get-lock-try-restarting-transaction/17748793
* https://dzone.com/articles/automatic-deadlock-retry
* https://github.com/SOCI/soci/issues/518
BTW: This locking issue is probably (but I'm not 100% sure..) completely unrelated to the other one tracked in FINERACT-859.
was:
The integration test logs sometimes show:
{{Deadlock found when trying to get lock try restarting transaction}}
I'm not clear whether those are log messages that can be ignored, because there is retry logic in place (e.g. in/by OpenJPA?), or if this indicates real failures which we must handle with a retry logic in the code... some background:
* https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlocks.html
* https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlock-example.html
* https://stackoverflow.com/questions/2332768/how-to-avoid-mysql-deadlock-found-when-trying-to-get-lock-try-restarting-trans
* https://stackoverflow.com/questions/17747906/getting-deadlock-found-when-trying-to-get-lock-try-restarting-transaction/17748793
* https://dzone.com/articles/automatic-deadlock-retry
* https://github.com/SOCI/soci/issues/518
> Deadlock found when trying to get lock try restarting transaction
> -----------------------------------------------------------------
>
> Key: FINERACT-856
> URL: https://issues.apache.org/jira/browse/FINERACT-856
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Michael Vorburger
> Priority: Major
>
> The integration test logs sometimes show:
> {{Deadlock found when trying to get lock try restarting transaction}}
> I'm not clear whether those are log messages that can be ignored, because there is retry logic in place (e.g. in/by OpenJPA?), or if this indicates real failures which we must handle with a retry logic in the code... some background:
> * https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlocks.html
> * https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlock-example.html
> * https://stackoverflow.com/questions/2332768/how-to-avoid-mysql-deadlock-found-when-trying-to-get-lock-try-restarting-trans
> * https://stackoverflow.com/questions/17747906/getting-deadlock-found-when-trying-to-get-lock-try-restarting-transaction/17748793
> * https://dzone.com/articles/automatic-deadlock-retry
> * https://github.com/SOCI/soci/issues/518
> BTW: This locking issue is probably (but I'm not 100% sure..) completely unrelated to the other one tracked in FINERACT-859.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)