...
To copy annotations to the query tables, the system leverages the asynchronous worker mechanism described here. As shown in the diagram below, when creating, updating or deleting a SubmissionStatus object, the repository services locks the (Submission-specific) SubmissionStatus etag as well as the (Evaluation-specific) Evaluation-SubStatus etag for update, updates the SubmissionStatus content, and queues a Change message. The Change message contains the evaluation Id, but not the Submission ID, i.e. it does broadcast which SubmissionStatus has been changed.
...
The Change message triggers the Annotations worker, which runs asynchronously with respect to the Client's request. It checks that the etag in the message matches the one in the repository service, to prevent against acting on "stale" Change messages. If the etags match, it runs a diff between the true state of the Evaluation's submission annotations (stored in the SubmissionStatus tables) and the state within the annotation query tables. Any differences are corrected updates are made in the query tables in a single transaction.
Batch SubmissionStatus Updates
Batch SubmissionStatus updates use the same semaphores as individual SubmissionStatus updates. Additionally we use optimistic concurrency across batches: Each batch contains a list of <n> SubmissionStatuses (with embedded annotations), along with flags for 'isFirstBatch' and 'isLastBatch', plus a batch 'token', required on all but the first batch. The system locks on the <n> SubmissionStatus etags as well as the Evaluation-SubStatus etag. commits the new SubmissionStatus data, and returns the new Evaluation-SubStatus etag as the 'nextUploadToken' in the client response. The client is required to include the returned token with the next subsequent batch. If, between batches, another client modifies any SubmissionStatus under the same Evaluation, then the batch token will not match the etag, and the client's request will be rejected with a PRECONDITION_FAILED (412) response. It is then the client's responsibility to restart the upload with the first batch. After the final batch the Change message is generated, triggering the asynchronous update of the Annotations query table.
...