You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 24, 2024. It is now read-only.
The schedule property, which is accessed by beat internally will update this local copy periodically via get_from_database().
However, get_from_database() calls sync() first before updating the dictionary:
If any Document is deleted from the PeriodicTask-Colleciton this will cause a SaveConditionError to be raised during the next get_from_database()-call. Mongoengine raises this error if an update did not update any documents (this is achieved by checking n_modified). This is always the case because the local copy is saved before fetching updates (even if its counterpart on the database no longer exists). This also causes similar race conditions when updating documents in the PeriodicTask-Collection (changes are sometimes overridden by the local copy).
Maybe the local copy should not be modified at all and therefore never be saved to the database. Instead it should only be periodically updated to avoid too many database requests.
Variables like total_run_count could be updated via atomic update so no race conditions occur.
Currently the scheduler tries to save all entries in its local copy of the schedule to the database in its
sync()-method:The
scheduleproperty, which is accessed by beat internally will update this local copy periodically viaget_from_database().However,
get_from_database()callssync()first before updating the dictionary:If any Document is deleted from the
PeriodicTask-Colleciton this will cause aSaveConditionErrorto be raised during the nextget_from_database()-call. Mongoengine raises this error if an update did not update any documents (this is achieved by checkingn_modified). This is always the case because the local copy is saved before fetching updates (even if its counterpart on the database no longer exists). This also causes similar race conditions when updating documents in thePeriodicTask-Collection (changes are sometimes overridden by the local copy).Maybe the local copy should not be modified at all and therefore never be saved to the database. Instead it should only be periodically updated to avoid too many database requests.
Variables like
total_run_countcould be updated via atomic update so no race conditions occur.