The new database handling uses postgresql Isolation level read for update and rows that have to be locked are selected with SELECT [...] FOR UDPATE. This leads to concurrency errors if two transactions try to select-for-update the same row.
This is reproducable by reverting the changes made in
https://github.com/OpenSlides/openslides-backend/pull/3313/changes#diff-91be329081a037edb9a2ae53ab4e7ebe89e081557c85df34875479c98eb606d5R32
To avoid immediate response to client with the error could not serialize access due to concurrent update we want to perform a retry of the called action on action-worker level.
The amount of retries should be configurable via ENV-variable (ACTION_RETRY_COUNT or something) with a default of 3 and there should be a wait between the retries also configurable via ENV (ACTION_RETRY_DELAY) with a default of 250ms.
The response to the client should be a user readable message like "Can not perform the current data changes. Please try again later".
The new database handling uses postgresql Isolation level
read for updateand rows that have to be locked are selected withSELECT [...] FOR UDPATE. This leads to concurrency errors if two transactions try to select-for-update the same row.This is reproducable by reverting the changes made in
https://github.com/OpenSlides/openslides-backend/pull/3313/changes#diff-91be329081a037edb9a2ae53ab4e7ebe89e081557c85df34875479c98eb606d5R32
To avoid immediate response to client with the error
could not serialize access due to concurrent updatewe want to perform a retry of the called action on action-worker level.The amount of retries should be configurable via ENV-variable (ACTION_RETRY_COUNT or something) with a default of 3 and there should be a wait between the retries also configurable via ENV (ACTION_RETRY_DELAY) with a default of 250ms.
The response to the client should be a user readable message like "Can not perform the current data changes. Please try again later".