Din løsning med flaget virker gennemførlig og jeg tror det eneste der skal til er at få låsen til at udløbe. Grundlæggende er den måde, jeg ville opbygge låsen på, at jeg ville skrive et tidsstempel, når låsen blev taget, og gøre det, så processen skulle opdateres låsen en gang imellem (dvs. hvert 30. sekund), mens den stadig arbejder på posten. Hvis processen dør eller på anden måde ikke fuldfører arbejdet, udløber låsen, og andre processer kan låse op det, hvis mere end det dobbelte af timeoutperioden udløber.
Når en proces er færdig med at arbejde på en post, vil den rydde låseflaget og markere posten som behandlet (igen endnu et flag).
Du vil sandsynligvis have to felter:et, der ville gemme tidsstemplets låseflag og et andet, der ville indikere, hvilken proces der ejer låsen (i tilfælde af at du bekymrer dig om det). Jeg går ud fra, at der er en eller anden form for nøgle, der kan bruges til at sortere posterne i tabellen, så begrebet "næste handling" er meningsfuldt.
Du kan bruge en forespørgsel som denne til at få den næste post, der skal behandles:
-- find the next available process and "lock" it by updating it's flag
UPDATE actions_tabe
SET LockFlag = @timestamp,
Process = @processname
WHERE Id IN (SELECT Id
FROM actions_table
WHERE LockFlag IS null
AND IsComplete = '0'
AND ScheduledTime < now()
ORDER BY Scheduledtime ASC, Id ASC
LIMIT 1);
-- return the Id and Action of the record that was just marked above
SELECT Id, Action
FROM actions_table
WHERE Process = @processname
Eksempel på violin her:http://sqlfiddle.com/#!11/9c120/26 /1