| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Timeout на выполнение метода(EJB) |
| Автор: alexadr 15.8.2008, 17:16 | ||
| Всем добрый день. Есть следующая задача: В процессе работы приложения дергается некий метод у некоего класса:
Данный метод может выполнятся сколь угодно долго. Мне необходимо, чтобы через некий таймаут приложение продолжило свою работу, даже если данный метод еще выполняется. Т.е. грубо говоря задача вызвать этот метод асинхронно с неким таймаутом. Сразу скажу, что вариант с дополнительным тредом уже есть. Это первое что пришло в голову. Также есть еще довольно тяжеловесное решение(связано с jms). Хотел узнать, если ли еще варианты. А самое главное, - есть ли возможность указать таймаут на выполнение метода в EJB. Сам это дело гуглил, но к сожалению нашел только таймаут на транзакцию для EJB, что не совсем то... |
| Автор: gEndelf 18.8.2008, 12:57 |
| как на счет использования Quartz ? или иже подобных шедулеров ? http://www.opensymphony.com/quartz/ |
| Автор: alexadr 18.8.2008, 13:13 |
| Это как вариант, но он по большому счету ничем не отличается от использования доп треда, т.к. внутри все равно поднимется дом тред, который будет выполнять некую Job. Конечно, плюс данного варианта в том что это уже более менее протестенная библиотека и с ней проблем быть не должно, я имею в виду кварц. |
| Автор: alexadr 19.8.2008, 17:57 |
| Да, в общем вывод в результате поисков/размышлений я сделал такие: 1. Единственный корректный способ реализации всего ентого, это использование JMS 2. Реализовывать енто с помощью доп потока в принципе возможно, только при этом необходимо писать(использовать) некий фреймворк, который бы мэнеджил эти доп треды и не давал бы расти их колличеству и чтоб это кол-во доп тредов могло быть сконфигурено, при этом по идее надо уменьшить в конфигурации j2ee сервера макс количество тредов как минимум на кол-во доп. тредов. |
| Автор: COVD 19.8.2008, 21:02 |
| для ваших целей достаточно применения new Thread , wait (long timeout) и notify. Однако чтобы вручную не программировать контроль количества создаваемых потоков проще воспользоваться пакетом java.util.concurrent - там разные варианты Executors , в том числе пулы с фиксированным количеством потоков. Чтобы вручную не программировать wait - notify можно применить submit, который возвращает java.util.concurrent.Future. У него есть метод public V get(long timeout, TimeUnit unit) , который блокируется и возвращает результат только после выполнения задачи или исключение по истечению таймаута. http://java.sun.com/docs/books/tutorial/essential/concurrency/exinter.html |
| Автор: alexadr 20.8.2008, 10:53 | ||||
Вот уж этого точно не достаточно, - этот подход уронит сервер на первой же пиковой нагрузке. А вот
это хороший вариант, только в этом случае приедтся настроить оптимальное макс кол-во тредов в пуле и при этом уменьшить макс кол-во тредов контейнера. |
