При запросе с клиента дёргаю МДБ - который вызывает оракловую процедуру. Процедура выполняется долго.

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



Это сообщение отредактировал(а) KostenkoSergey - 20.9.2006, 11:43

Можно. 
Вариант 1. Использовать класс java.util.Timer из стандартной библиотеки. Но он долвольно ограничен, хотя для этой задачи его возможностей вроде хватит. 
Вариант 2. Использовать библиотеку Quartz, которая позволяет задавать cron-like выражения для определения времен запуска. 
Вариант 3. В J2EE есть свой таймеры, подробности здесь - http://forum.vingrad.ru/index.php?showtopic=105100.

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

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

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

Что не доглядел? Таймер стандартный?

Перестартанёшь сервер - отсчёт свалится

Это сообщение отредактировал(а) chief39 - 20.9.2006, 21:52

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

Это сообщение отредактировал(а) w1nd - 21.9.2006, 11:21

chief39, чего отвалится?  Если грамотоно сделать - не отвалится.

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

Естественно, я не буду спорить про "стандартность" или там еще какие-то характеристики такого подхода, но - оно работает.

Может в вашем случае оно и работает, но не факт, что будет работать у кого-то ещё.

Как правило, необходимость перезапускать сервер возникает только тогда, когда с ним творится что-нибудь непотребное, а в этот момент зачастую сделать уже ничего нельзя. Нельзя быть уверенным даже в исполнении shutdown hook'ов.

И речь идет не о "стандартности", а о применимости. Управление потоками в J2EE недопустимо, а попытки делать это могут привести как раз к необходимости регулярно перезапускать сервера  Кстати, в кластере J2SE-шный таймер не будет работать никогда.

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

Ну дык и что? Кто мешает сохранять состояние task-pool в момент изменения списка заданий? И ничего страшного не произойдет даже при том, что сервер вывалится потом, когда 




Sorry, опять же, не согласен - все зависит от грамотности реализации. Не вижу ничего "недопустимого" в этом. Управление потоками - нормальная практика на любой платформе.

Лично мне мешает необходимость реализации этого самого taskpool'а, тогда как таймеры со всей необходимой инфраструктурой в J2EE 1.4 уже есть 



На любой, кроме J2EE. Внутри сервера приложений это ненормальная практика. Если вы не видите ничего недопустимого -  почитайте спецификацию.

Если вам лень читать, то я примерно обрисую пару ситуаций:

• На сервере выполняется N приложений, одно из них вдруг решает управлять всеми остальными. Комментарии, как говорится, излишни. 
• Сервер постоянно производит мониторинг своих внутренних подсистем, на основании результатов которого делает выводы о загруженности и либо сигнализирует админу, либо перекидывает запросы на другие узлы кластера, либо отказывает в обслуживании вновь подключившимся клиентам. В случае с вышеупомянутым "самостоятельным" приложением сервер никогда не узнает о том, что его ресурсы исчерпаны.

Вобщем ясно   

Это уже попахивает "религиозной войной" в подходах.   Шучу.

А если серьезно - просто обратите внимание на "достаточность" данного метода. То, о чем я говорю - простое и эффективное решение в контексте не гугловского масштаба запросов клиентов. Собственно, по-моему в конкретном, данном, вопросе кластеры и распределение нагрузки ни причем (KostenkoSergey, если я ошибаюсь - поправьте меня, и сорри всем остальным).

Реализация такого пула - это дело десяти минут, хеш-мапа и шести методов. Т.ч. - это нормальная практика.

А JMX для таких вещей по-моему сильно "жирно"   

Я уж не знаю, какими доводами мне воспользоваться, так что повторюсь. Не имеет значения, собираетесь ли вы разворачивать кластер или нет, есть ли вам дело до живучести сервера - если вы пишете J2EE приложение, вы должны придерживаться некоторых правил, определенных спецификацией. Если вас не устраивают существующие правила - пишете (или собираете - благо готовых компонентов для этого навалом) собственный сервер.   

Вторая мысль - считаю недальновидным игнорирование имеющегося инструментария и написание своих аналогов. На работе я за это людей наказываю  

З. Ы. Про "жирность": почему вы так считаете?

Это сообщение отредактировал(а) w1nd - 23.9.2006, 01:28

Тут еще много зависит от используемого Application Server-а. Скажем, на WebLogic-е есть такая вещь, как отложенная доставка сообщения - при его посылке мы указываем время, когда оно должно быть доставлено: http://e-docs.bea.com/wls/docs81/jms/implement.html#1235262