Replace Tooz project locking in taskflowbackend? #1844
Labels
app: taskflowbackend
Issue in the taskflowbackend app
environment
Issues of dependencies, CI, deployment etc.
feature
Requested feature or enhancement
tbd
Comments wanted, spec/schedule/prioritization to be decided, etc.
The use of Tooz to handle project locking and unlocking in taskflowbackend is a remnant of the days when we used the separate SODAR Taskflow microservice for these transactions. In that case, a project object was not available so this made sense.
Now that these are integrated, I'm not sure if using this mechanism is required. Also, no other functionality in SODAR currently considers the taskflow locks for a project, so e.g. a sheet replacing operation can be triggered even while the project is "locked".
Perhaps it would be better to e.g. introduce a
Project
level locking mechanism within SODAR Core with relevant rules and APIs and use that here. The functionality could then be easily extended to other lockable features without the need for an extra library dependency and an external database (redis). Timing out the locks could be handled with a periodic celery job.This would also enable sites other than SODAR to use such general-purpose locking. Not to mention this would go well with bihealth/sodar-core#24, which will be implemented soon anyway. This would make #1841 unnecessary as similar functionality would be implemented in SODAR Core.
..unless there's an advantage to Tooz I'm can't think of right now?
Something to consider, comments are welcome.
The text was updated successfully, but these errors were encountered: