Специально для staranchenko

[beldmit]

Серега, тебе будет интересно - речь про обработу очереди. И Богуку покажу.

Раз: http://yakov-sirotkin.livejournal.com/103083.html

Два: http://dmih.livejournal.com/429785.html

Три (по наводке из предыдущей): http://dklab.ru/chicken/nablas/53.html

Кстати, коллеги - IT-шники, dmih рекомендую всячески, очень здравый подход.

Comments

[ask-ripe.livejournal.com]

дима, а давай я как-нибудь к вам заеду и расскажу почему все трое (ок, только яков и дмих) ахтунги...
gor

[beldmit.livejournal.com]

Ну давай...

[staranchenko.livejournal.com]

По поводу первого пункта. Я не очень понял автора, если честно. :-) У меня это делается так: выбираем N первых заданий, соответствующих критериям (порядок создания, приоритет, отсутствие зависимостей, задание не взято в обработку и пр.), пробегаем по ним циклом и пытаемся заблокировать одно из них, если получилось - прописываем, что взяли задание в обработку (в случае PostgreSQL это PID + дата старта backend-процесса PostgreSQL) и возвращаем заблокированное задание. Соответственно, критерий "взято в обработку" реализован как "существует процесс с таким PID и датой старта в момент выборки". При успешном выполнении задание удаляется, в случае неуспеха откладывается на какое-то время. Такой подход дает возможность брать задания в несколько потоков, исключить выполнения задания дважды и даже не иметь зависших локов при падении серверных процессов.

По поводу второго и третьего пунктов. Такой подход применим только для примитивных систем. Зависимости между заданиями, например, там невозможны.