Pull to refresh
8
0
Андрей @andreysapegin

User

Send message
Отказались мы от такого подхода (вариант 2), т. к. приходилось дёргать разработчика, чтобы в нужное время посмотреть на функционал.
Мы указываем в конфигурации префиксы к таблицам БД, к ключам nosql, к названиям очередей, также под отдельные задачи могут меняться ссылки на внешние сервисы. В основном тогда, когда задача требует изменений в структуре данных. В остальных случаях используем общую тестовую среду.
Основная задача механизма блокировки в том, чтобы дать только 1-му процессу право пользоваться каким-то ресурсом на заданное время.

Как этим ресурсом пользуется процесс (и пользуется ли вообще) для механизма блокировки совершенно не важно.

Так, например, процесс может брать лок на 25 секунд не только для того, чтобы успеть закончить работу за это время, но и оставить существенный запас для снижения нагрузки. Сам процесс отработает за несколько секунд и завершит свою работу, а лок должен остаться до конца заданного времени.

Или в случае, если процессу нужно несколько разных локов, то получается, если один из них он не успел продлить, то его убьют из-за этого?

Я к тому, что если в конкретном случае нужна жёсткая зависимость «лок — процесс», то тогда да, можно отдельно прикрутить и такую логику, но это далеко не общий случай.
DmitryKoterov правильно отметил, что простого экспайра недостаточно.
При продлении важно знать кем была поставлена эта блокировка, особенно в случае, если она просрочена, но ещё не занята другим процессом.
Снимать автоматом при смерти процесса не всегда возможно, именно поэтому блокировка ставится на разумное время, чтобы она сама снималась.

При протухании блокировки убивать процесс несколько странно на мой взгляд.
Гугл не парится этим вопросом: www.google.com/apps/intl/hi/business/index.html
В Алаваре сделали с подписью на английском www.alawar.es/
В фейсбуке: перечислили основные: www.facebook.com/

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity