Добрый день.
Столкнулся с проблемой при работе с таймерами в EJB 3.0
Если вызывать из сервлета метод бина, который только создает таймер, а затем, в другом методе обрабатывает этот таймер по таймауту, то всё работает.
Но если таймер создается внутри большого бизнес-метода бина, то получаю EJBException.
В чем дело и как побороть?

Итак, в бизнес-методе бина делаю так:
где context объявлена как


получаю ошибку

Вот то, что у меня работает на JBOSS и WebSphere


Инждектися прямо TimerService, из вне вызывается бизнес-метод createTimer с датой начала, периодом повторения в миллисекуднах и просты Серриализуемым объектом TimerInfo (самописный).
Возможно у тебя проблема, что уже такой таймер создан? Тогда стоит сначала вызвать такой как у меня метод stopTimer

Добавлено через 6 минут и 2 секунды
Да, есть еще такой пример. Все это будут методы одного EJB


Так что где-то что-то у тебя с количеством экземпляров самого TimedObject

MisterCleric, проблема в том, что просто создание таймера работает

однако, если добавить вызов другого jpa бина

то получается исключение java.lang.IllegalStateException: Unable to persist timer
а в логах есть такая информация:
где этот параметр можно изменить?

Собственно я так понимаю, что проблема тут кроется как раз в том, что объекты таймеров сохраняются в базу; и я уверен, что ты используешь Hypersonic, датасоурс которого local-tx-datasource, и никак не XA, как надо для распределенной транзакции в твоем случае. 
Тут происходит такое: 
1. ты стартуешь транзакцию вызывая метод createTimer
2. Она накладывается на userManager.findUserByEmail, если не указаны никакие транзакционные атрибуты на этом методе.
3. Эта же транзакция распостраняется на timerService.createTimer
4. В результате выходит, что одна и та же транзакция ложиться на две базы.
5. Поскольку local-tx-datasource не поддерживает двухфайзные транзакции, то и валится эксепшн.

Решения могут быть такими

1. Помечаешь свой метод userManager.findUserByEmail как не транзакционный @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
2. Выносишь timerService.createTimer в отдельный метод
3. Сделать DefaultDS xa-datasource и создать все таблицы менеджмента JBOSS в твоей базе

Вот мой пример, который работает на local-tx-datasource:


Все в отдельных методах и все с транзакцией по умолчанию

Да, Hypersonic, по умолчанию.

Есть ли другие способы решения?
Дело в том, что на одном сервере могут быть несколько приложений, каждое из которых работает со своей собственной базой, и каждое из которых работает с таймерами? Поэтому создать все таблицы менеджмента JBOSS в собственной базе в таком случае невозможно.

Тогда крути другие способы. Хотя я не представляю, как у заказчика будет стоять такой JBOSS, на котором работает несколько разных по бизнесу приложений. Такие приложения должны стоять на разных JBOSS. У меня практика поставлять один AS под одно приложение. Один JBOSS - это одна java-машина. Не сильно ли напряжно для нее выполнять в одно и тоже время разные EE-приложения? А если они еще у тебя и вэбовские? Надо ж не забывать, то у tomcat тоже ж ресурсы ограничены... 
JBOSS - он же бесплатный, зачем экономить на инстансах для каждого приложения?

Слушай, еще могу предложить такое:
в *-service.xml, который отвечает за TimerService, ну в общем найдешь по моему примеру, который будет следовать дальше



мне такое понадобилось, когда разворачивал свое приложение в кластере. И если я сохранял таймеры в базу, то при старте второго нода срабатыва метод timeout, что естественно по логике приложения не должно было быть. и того меня политика "несохранения таймеров" спасла.

Не удалось мне добиться этого на MySQL, а вот на Postgres заработало сразу и без проблем

Это сообщение отредактировал(а) YuG - 18.5.2009, 17:42

Нашел вот такое решение по MySQL:
BUG