Skip to content

prevent concurrent recruitment

Bengfort requested to merge recruitment-lock into main

Concurrency issues in castellum are usually dealt with by leaning heavily on the integrity guarantees of the database. The user experience is not our first priority in those cases. For example, if I want to delete a study and another user deletes that study exactly between my GET and POST requests, I will get an error message. Race conditions like this are pretty rare in practice though.

In mail recruitment, we first get a list of suitable subjects, then send a mail to each one, and then create participations for all of them. The database makes sure that no subject can be added twice. So if another user create a participation for a subject while we are busy sending mails, the final step will fail.

This case is special for a couple of reasons

  • Sending mails is slow, so races are more likely. It is also common that we add 100 or more subjects in a single request, which also makes this slow.
  • Sending mails is a side effect that exists outside of the database, so it is not covered by database integrity guarantees.
  • If we send out mails to subjects and then do not create participations for them, we might end up sending mails to the same subjects again. Not annoying the subjects is super important.

As a solution I added a locking mechanism, so that only one request can add participations to a study.

I used try … finally to prevent deadlocks. This is not 100% reliable (e.g. if the power is cut of) but this should get us pretty far. Locks can still be removed manually, e.g. if they do still exist after 5 minutes.

Merge request reports