Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java EE (J2EE) и Spring > J2EE и отложенное выполнение

Автор: KostenkoSergey 20.9.2006, 11:39

При запросе с клиента дёргаю МДБ - который вызывает оракловую процедуру. Процедура выполняется долго. Можно как то планировать время выполнения фрагмента кода в ЕЕ (например выполнить код вызова процедуры строго в 3 часа ночи) (без oracle jobs)

Автор: tux 20.9.2006, 11:52

Цитата(KostenkoSergey @  20.9.2006,  16:39 ) Можно как то планировать время выполнения фрагмента кода в ЕЕ Можно.  Вариант 1. Использовать класс http://java.sun.com/j2se/1.5.0/docs/api/java/util/Timer.html из стандартной библиотеки. Но он долвольно ограничен, хотя для этой задачи его возможностей вроде хватит.  Вариант 2. Использовать библиотеку http://www.opensymphony.com/quartz/, которая позволяет задавать cron-like выражения для определения времен запуска.  Вариант 3. В J2EE есть свой таймеры, подробности здесь - http://forum.vingrad.ru/index.php?showtopic=105100.

Автор: sergakrem 20.9.2006, 14:31

Я вот только недавно решал такую же задачу - чудесно получилось с помощью java.util.Timer + поток на каждый запрос (но это уже особенности архитектуры приложения).  У меня есть singletone объект. (task pool) который доступен приложению, и  в котором регистрруются задачи со временем их выполнения. Вот собственно и все.

Автор: KostenkoSergey 20.9.2006, 19:01

спасибо -  не доглядел - думаю java.util.Timer будет вполне достаточно.

Автор: chief39 20.9.2006, 21:50

Цитата(KostenkoSergey @  20.9.2006,  19:01 ) спасибо -  не доглядел  Что не доглядел? Таймер стандартный? Перестартанёшь сервер - отсчёт свалится

Автор: w1nd 21.9.2006, 11:19

Использовать java.util.Timer на стороне сервера нельзя. По крайней мере, если считаете, что можете делать то, на что сервер не рассчитан - используйте JMX-таймер (пакет javax.management.timer). В этом случае можно хотя бы надеяться на его работоспособность после перезапуска сервера.

Автор: sergakrem 21.9.2006, 17:48

chief39, чего отвалится?  Если грамотоно сделать - не отвалится. Можно узнаь о событии останова сервера, записать task-pool с его текущим состоянием (таски и время их выполения), а при последующем старте выполнить необходимые телодвижения по восстановлению состояния пула (и, если надо - выполнить/ли нет те задачи, которые просрочены) - собственно в моем случае оно так и происходит. Естественно, я не буду спорить про "стандартность" или там еще какие-то характеристики такого подхода, но - оно работает.

Автор: w1nd 21.9.2006, 21:40

Цитата(sergakrem @ 21.9.2006,  17:48) chief39, чего отвалится?  Если грамотоно сделать - не отвалится. Можно узнаь о событии останова сервера, <...> Естественно, я не буду спорить про "стандартность" или там еще какие-то характеристики такого подхода, но - оно работает. Может в вашем случае оно и работает, но не факт, что будет работать у кого-то ещё. Как правило, необходимость перезапускать сервер возникает только тогда, когда с ним творится что-нибудь непотребное, а в этот момент зачастую сделать уже ничего нельзя. Нельзя быть уверенным даже в исполнении shutdown hook'ов. И речь идет не о "стандартности", а о применимости. Управление потоками в J2EE недопустимо, а попытки делать это могут привести как раз к необходимости регулярно перезапускать сервера  Кстати, в кластере J2SE-шный таймер не будет работать никогда.

Автор: COVD 21.9.2006, 22:23

Цитата Использовать java.util.Timer на стороне сервера нельзя а мы вовсю используем. Например, нам надо в 5 утра каждый день делать нечто. Перезапуск сервера не помеха, надо просто правильно выставить время первого срабатывания таймера. Легко вычисляется на основании системного времени  в момент рестарта сервера. Сервер рестартует и таймеры заново устанавливаются.

Автор: sergakrem 21.9.2006, 23:28

Цитата(w1nd @  21.9.2006,  21:40 ) Как правило, необходимость перезапускать сервер возникает только тогда, когда с ним творится что-нибудь непотребное, а в этот момент зачастую сделать уже ничего нельзя. Нельзя быть уверенным даже в исполнении shutdown hook'ов. Ну дык и что? Кто мешает сохранять состояние task-pool в момент изменения списка заданий? И ничего страшного не произойдет даже при том, что сервер вывалится потом, когда  Цитата(w1nd @  21.9.2006,  21:40 ) сделать уже ничего нельзя Цитата(w1nd @  21.9.2006,  21:40 ) Управление потоками в J2EE недопустимо, а попытки делать это могут привести как раз к необходимости регулярно перезапускать сервера Sorry, опять же, не согласен - все зависит от грамотности реализации. Не вижу ничего "недопустимого" в этом. Управление потоками - нормальная практика на любой платформе.

Автор: w1nd 22.9.2006, 15:28

Цитата(sergakrem @ 21.9.2006,  23:28) Ну дык и что? Кто мешает сохранять состояние task-pool в момент изменения списка заданий? Лично мне мешает необходимость реализации этого самого taskpool'а, тогда как таймеры со всей необходимой инфраструктурой в J2EE 1.4 уже есть  Цитата(sergakrem @ 21.9.2006,  23:28) Sorry, опять же, не согласен - все зависит от грамотности реализации. Не вижу ничего "недопустимого" в этом. Управление потоками - нормальная практика на любой платформе. На любой, кроме J2EE. Внутри сервера приложений это ненормальная практика. Если вы не видите ничего недопустимого -  почитайте спецификацию. Если вам лень читать, то я примерно обрисую пару ситуаций: На сервере выполняется N приложений, одно из них вдруг решает управлять всеми остальными. Комментарии, как говорится, излишни.  Сервер постоянно производит мониторинг своих внутренних подсистем, на основании результатов которого делает выводы о загруженности и либо сигнализирует админу, либо перекидывает запросы на другие узлы кластера, либо отказывает в обслуживании вновь подключившимся клиентам. В случае с вышеупомянутым "самостоятельным" приложением сервер никогда не узнает о том, что его ресурсы исчерпаны.

Автор: sergakrem 22.9.2006, 16:21

Вобщем ясно    Это уже попахивает "религиозной войной" в подходах.   Шучу. А если серьезно - просто обратите внимание на "достаточность" данного метода. То, о чем я говорю - простое и эффективное решение в контексте не гугловского масштаба запросов клиентов. Собственно, по-моему в конкретном, данном, вопросе кластеры и распределение нагрузки ни причем (KostenkoSergey, если я ошибаюсь - поправьте меня, и сорри всем остальным). Реализация такого пула - это дело десяти минут, хеш-мапа и шести методов. Т.ч. - это нормальная практика. А JMX для таких вещей по-моему сильно "жирно"

Автор: w1nd 23.9.2006, 01:24

Цитата(sergakrem @ 22.9.2006,  16:21) Вобщем ясно    Это уже попахивает "религиозной войной" в подходах.   Шучу. А если серьезно - просто обратите внимание на "достаточность" данного метода. То, о чем я говорю - простое и эффективное решение в контексте не гугловского масштаба запросов клиентов. Собственно, по-моему в конкретном, данном, вопросе кластеры и распределение нагрузки ни причем (KostenkoSergey, если я ошибаюсь - поправьте меня, и сорри всем остальным). Реализация такого пула - это дело десяти минут, хеш-мапа и шести методов. Т.ч. - это нормальная практика. А JMX для таких вещей по-моему сильно "жирно"   Я уж не знаю, какими доводами мне воспользоваться, так что повторюсь. Не имеет значения, собираетесь ли вы разворачивать кластер или нет, есть ли вам дело до живучести сервера - если вы пишете J2EE приложение, вы должны придерживаться некоторых правил, определенных спецификацией. Если вас не устраивают существующие правила - пишете (или собираете - благо готовых компонентов для этого навалом) собственный сервер.    Вторая мысль - считаю недальновидным игнорирование имеющегося инструментария и написание своих аналогов. На работе я за это людей наказываю   З. Ы. Про "жирность": почему вы так считаете?

Автор: Lerm 26.9.2006, 01:24

Цитата(KostenkoSergey @ 20.9.2006,  11:39) При запросе с клиента дёргаю МДБ - который вызывает оракловую процедуру. Процедура выполняется долго. Можно как то планировать время выполнения фрагмента кода в ЕЕ (например выполнить код вызова процедуры строго в 3 часа ночи) (без oracle jobs) Тут еще много зависит от используемого Application Server-а. Скажем, на WebLogic-е есть такая вещь, как отложенная доставка сообщения - при его посылке мы указываем время, когда оно должно быть доставлено: http://e-docs.bea.com/wls/docs81/jms/implement.html#1235262

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)