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?
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
Projectlevel 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.