Avoid race conditions when working with Batch Session Data
JATOS' batch session data seems like very powerful way to implement things like counterbalancing. In the case of counterbalancing, you could start by defining a list of (say) 30 conditions in the batch session data, and then at the start of each experimental session get the available conditions from the server, select one, remove it from the list, and update the available conditions on the server (as described here).
This seems to work quite well but I'm afraid that it will run into race conditions when recruiting many participants through a service such as Prolific, because they all start around the same time. And in that case it can happen that two near-simultaneous sessions get the same list of available conditions, each remove one, and then when the available conditions are updated on the server, the second session actually overwrites the update of the first session. I hope that makes sense.
So my question is: is there a straightforward way to avoid race conditions like this when working with batch session data?