Вам спасибо за подобный продукт! Кстати, могу отметить, что благодаря JPA-Buddy в лишний раз убедился в том, что разработка веб-приложений с каждым годом становится все более доступным и легким, благодаря большому количеству библиотек, плагинов и утилит.
Вы можете не тащить inMemory к себе в проект, а воспользоваться другим, более оптимальным для себя решением. Есть проекты, где HazelCast уже присутствует, и не вижу ни одной причины почему не использовать его для решения подобных задач. Вариант с библиотекой Quartz был, но отпал, так как мне не понравилась его "многословность", слишком разветвленное API и малое количество документации. В моем кейсе я решил не отказываться от Spring Scheduler, где все решение упрощается в одну аннотацию.
1)В этом и заключается смысл работы метода sleep(4000). По факту, нам ни OC, ни Springне будут гарантировать выполнение метода с точностью до миллисекунд, исходя из этого одна из нод всегда будет опаздывать и стучаться в метод повторно, как показано на первых скринах консоли. Усыпляя один из потоков на 4 секунды, мы предовтращаем возможность повторного доступа к методу для опаздывающего потока.
2)IMap как раз эту проблему решает. Решение намного лучше, чем использование sleep(). Ведь успыпление потока не будет 100% гарантией, потому что второй может опоздать и на больше, чем 4000мс - например, у него случился GC. Можно еще организовать голосование между нодами, чтобы они выбрали лидера. Тогда в момент срабатывания расписания, каждый проверяет, лидер он или нет, и только лидер делает работу. Но по сравнению с IMap - это как из пушки по воробьям.
Не совсем понятно, что имеется ввиду в последнем предложении. Лок не должен все время держать метод, ведь его задача задержать его лишь на несколько секунд, пока нода №2 не обламается. И к тому же, стоит отметить, что интервал в 5 секунд для sheduler'а - это тестовое значение, ведь на практике 5 секундных триггеров встречается крайне мало, в основном это интервалы раз в день или раз в час. Как минимум IMAP - это гарантия того, что метод отработает один раз. Как я написал выше, в статье, исходя из моего опыта реализации других решений, вариант с распределенной картой показал лучший результат, в том числе и по чистоте, хотя до начала работы с ним мне показалось, что это больше "костыльное" решение. Плюс ко всему HazelCast предоставляет UI management-center для работы со всей библиотекой, что очень удобно использовать в отладке, ведь там можно в режиме live смотреть состояния объектов, в том числе и распределенных.
Добрый день! Увеличение количества работников в данном регионе не будет вызывать понижения зарплат, так как спрос очень сильно превышает предложение.
Однозначно)
Вам спасибо за подобный продукт!
Кстати, могу отметить, что благодаря JPA-Buddy в лишний раз убедился в том, что разработка веб-приложений с каждым годом становится все более доступным и легким, благодаря большому количеству библиотек, плагинов и утилит.
Не плохая статья
Отличная статья! Прочитал на одном дыхании. Глубокого смысла искать не надо, каждому свое)
Добрый день! Спасибо за полезный комментарий! Обязательно ознакомлюсь с этой проблемой. До этого момента про это не знал.
Вы можете не тащить inMemory к себе в проект, а воспользоваться другим, более оптимальным для себя решением. Есть проекты, где HazelCast уже присутствует, и не вижу ни одной причины почему не использовать его для решения подобных задач. Вариант с библиотекой Quartz был, но отпал, так как мне не понравилась его "многословность", слишком разветвленное API и малое количество документации. В моем кейсе я решил не отказываться от Spring Scheduler, где все решение упрощается в одну аннотацию.
Павел, спасибо!
1) В этом и заключается смысл работы метода sleep(4000). По факту, нам ни OC, ни Spring не будут гарантировать выполнение метода с точностью до миллисекунд, исходя из этого одна из нод всегда будет опаздывать и стучаться в метод повторно, как показано на первых скринах консоли. Усыпляя один из потоков на 4 секунды, мы предовтращаем возможность повторного доступа к методу для опаздывающего потока.
2) IMap как раз эту проблему решает. Решение намного лучше, чем использование sleep(). Ведь успыпление потока не будет 100% гарантией, потому что второй может опоздать и на больше, чем 4000мс - например, у него случился GC. Можно еще организовать голосование между нодами, чтобы они выбрали лидера. Тогда в момент срабатывания расписания, каждый проверяет, лидер он или нет, и только лидер делает работу. Но по сравнению с IMap - это как из пушки по воробьям.
Не совсем понятно, что имеется ввиду в последнем предложении. Лок не должен все время держать метод, ведь его задача задержать его лишь на несколько секунд, пока нода №2 не обламается. И к тому же, стоит отметить, что интервал в 5 секунд для sheduler'а - это тестовое значение, ведь на практике 5 секундных триггеров встречается крайне мало, в основном это интервалы раз в день или раз в час. Как минимум IMAP - это гарантия того, что метод отработает один раз. Как я написал выше, в статье, исходя из моего опыта реализации других решений, вариант с распределенной картой показал лучший результат, в том числе и по чистоте, хотя до начала работы с ним мне показалось, что это больше "костыльное" решение. Плюс ко всему HazelCast предоставляет UI management-center для работы со всей библиотекой, что очень удобно использовать в отладке, ведь там можно в режиме live смотреть состояния объектов, в том числе и распределенных.