Хотелось бы как-то прояснить этот момент.
Допустим, у нас есть некая потребность сформировать какой-то отчёт в Exel. У нас есть какая-то очень длительная выборка из СУБД и мы что-то в отчёт вставляем. Формируем его JasperReport'ом.
Инициатором начала формирования отчёта является Stand Alone Java Client с GUI Swing интерфейсом.
Если использовать просто Remote SessionBean, то если отчёт формировался бы достаточно долго, то клиент просто отвалился бы по TimeOut'у.
Это всё равно кабы я пришёл за колбасой в магазин и сказал продавщице: "Хочу колбасы!"
А она: "Несу!"
И остался бы ждать.
Прошло 30 мин (например), я по TimeOut развернулся у ушёл и никогда бы больше не пришёл.
Пришла бы продавщица через 2 часа и вызвала бы исключение.
А вот в случае с MessageDrivenBean:
Пришёл бы я в магазин за колбасой и крикнул бы: "Хочу колбасы!"
И ушёл бы не дожидаясь бы ответа от продавщицы.
А вот вопрос: Может ли продавщица меня как-то уведомить, например, послать мне Клиенту сообщение о том, что колбаса готова, а я бы увидев сообщение пошёл бы в магазин за колбасой.
Или я должен буду как демон бегать в магазин каждые 5 минут и спрашивать у какого-нибудь Sigleton'а (так к примеру): "Готова ли колбаса?" До тех пор пока он не скажет: "Готова!"
И самое главное никто ли не отвалится в этой схеме?

авторТретий человек связывается с вами и говорит вам "вам колбаса".
Вот в этом-то и вопрос как он связываться должен.
Я тут немного почитал:
Then EJB specification does not outline any mechanism that allows a JMS message-driven bean to propagete a response back to the client that oroginally generated the message.
Типа, нет стандартных механизмов для того, чтобы Message Driven Bean как-то уведомил источник сообщения, в данном случае клиента.
авторВам нужен третий персонаж, находящийся у прилавка.
Ну, это да. Например, это может быть некий Singleton, как вариант, или JMS-очередь. Singleton как-то понятнее был бы, на мой взгляд.
Но в любом случае надо будет бегать каждые какие-то секунды и спрашивать не готова ли колбаса, потому что E-mail может не везде использоваться.

Я вот сейча решил попробовать. Сделал серверу вечный цикл:


Вроде, пока работает уже часа полтора и ничего не отваливается.

Внутри mdb лучше не делать длительных операций, в конце-концов, у контейнера есть таймауты.
JMS тут наверное не очень подходит, JMS хорошо когда много сообщений.
Уже часа 2 работает.
Может быть этот TimeOut просто большой и я его не дождался пока.
Ну, а как тогда быть с длительными операциями, если они есть или могут быть?
Есть ли какая-то общая тактика?
Лучше писать задачи об отчете в таблицу, а потом в отдельном потоке дергать её и формировать отчеты.
А это как это?


Так что ли?
Или нет?

в конце-концов, у контейнера есть таймауты.
То есть у MessageDrivenBean TimeOut'ы есть, а у @Schedule нет что ли TimeOut'ов?
Просто у SessionBean они точно есть. Пока я ходил на обед - они случались. Там TimeOut довольно большой, но и не слишком большой одновременно.

Я не пойму каким боком тут вообще таймауты?
Вам же предельно ясно обьяснили - надо разбить задачу на несколько компонентов. Компонент 1 - добавляет заявку на длительную операцию в посредник. Компонент 2(посредник) - передает заявку в систему где она обрабатывается(компонент 3) и запускает таймер в зависимости от задачи, в котором опрашивается система на наличие обработанной заявки. Когда заявка обработана - таймер удаляется, компонент 1 оповещается и забирает результат. Какие тут таймауты?
Как это конкретно реализовать - ну можно и через очереди, вариантов миллион
забыл ник просто у меня начинают возникать сомнения на счёт того, что Лагман прав на счёт того, что у Message Driven Bean'а есть TimeOut. Я запустил сервер на debug. Ставлю в цикл break point и вижу, что поток на сервере работает до сих пор. И пока нет никаких TimeOut'ов.
...и запускает таймер...
Ну, вот я и думаю, а если нет у Message Driven Bean'а никаких TimeOut'ов, то есть если его запустить, то он может работать вечно, то может быть его и использовать для длительных операций, а не таймер.
Просто таймер мне кажется менее привлекательной штукой по сравнению с Message Driven Bean'ом.

Я попробую это всё до завтра оставить. Если ничего не отвалится, то, наверное, можно считать, что Лагман вероятно ошибился и Message Driven Bean может работать вечно и хорошо подходит для длительных операций, инициализированных клиентом.
А может и я ошибаюсь... кто знает...

Очередь заэкспайрит мессадж если бин долго будет молотить. И количество истанциированных контейнером MDB увеличиться(при большом таймауте очереди).
У сервера есть ограничение на количество MDB.

Я ради интереса на ночь всё это оставил. Пришёл сейчас утром - ничего не отвалилось break ставится и перехватывает выполнение.
ejb 3.1 asynchronous session beans
Есть даже такие штуки...
Но по сути Message Driven Bean то же самое. И он ведёт себя так как мне нужно. Единственное, что надо учесть - это то что по своей природе он Stateless и их может существовать не более чем указано в настройках сервера, а иначе, вероятно, произойдёт глобальное исключение.
Ну, значит, делаем вывод, что Лагман был не прав и у Message Driven Bean нет никаких TimeOut и их вполне можно использовать для длительных операций.

есть
Ну, а сколько. Он у меня почти сутки отработал в вечном цикле и ничего никаких TimeOut'ов не было.
Каков же этот TimeOut? Неделя, месяц или год?

в websphere 6.1, например, по умолчанию 120 секунд
А в Glassfish около суток как минимум. Как практика показала.

я посмотрю завтра
Ну, и как результаты тестов?