Som du nævner, er der i øjeblikket ingen ren måde at gøre, hvad du vil. Den bedste tilgang på nuværende tidspunkt til operationer som den, du har brug for, er denne:
- Læseren vælger X dokumenter med passende grænse og sortering
- Reader markerer de dokumenter, der returneres af 1) med sit eget unikke læser-id (
e.g. update({_id:{$in:[<result set ids>]}, state:"available", $isolated:1}, {$set:{readerId:<your reader's ID>, state:"processing"}}, false, true)) - Reader vælger alle dokumenter, der er markeret som behandlede og med sit eget læser-id. På dette tidspunkt er det garanteret, at du har eksklusiv adgang til det resulterende sæt af dokumenter.
- Tilbyd resultatsættet fra 3) til din behandling.
Bemærk, at dette endda fungerer i meget samtidige situationer, da en læser aldrig kan reservere dokumenter, der ikke allerede er reserveret af en anden læser (bemærk, at trin 2 kun kan reservere aktuelt tilgængelige dokumenter, og skrivninger er atomare). Jeg vil også tilføje et tidsstempel med reservationstid, hvis du vil være i stand til at time-out reservationer (for eksempel for scenarier, hvor læsere kan gå ned/fejle).
EDIT:Flere detaljer:
Alle skriveoperationer kan lejlighedsvis give efter for ventende operationer, hvis skrivningen tager relativt lang tid. Det betyder, at trin 2) muligvis ikke ser alle dokumenter, der er markeret med trin 1), medmindre du udfører følgende trin:
- Brug en passende "w"-værdi (skriv bekymring), hvilket betyder 1 eller højere. Dette sikrer, at forbindelsen, som skrivehandlingen påkaldes på, venter på, at den er fuldført, uanset om den giver efter.
- Sørg for, at du læser i trin 2 på den samme forbindelse (kun relevant for replikasæt med slaveOk-aktiverede læsninger) eller tråd, så de er garanteret sekventielle. Førstnævnte kan gøres i de fleste drivere med metoderne "requestStart" og "requestDone" eller lignende (Java-dokumentation her
).
- Tilføj $isolated-flaget til dine multi-opdateringer for at sikre, at det ikke kan interleaves med andre skriveoperationer.
Se også kommentarer til diskussion vedrørende atomicitet/isolation. Jeg antog fejlagtigt, at flere opdateringer var isolerede. Det er de ikke, eller i det mindste ikke som standard.