dymkaПо событию таймера нужно запустить долгий процесс (для этого стартуем поток).
Скорее я просто не понимаю концепцию EE...
Если вы собираетесь понять концепции EE, то начните хотя бы с чтения EE спецификации. Это относительно небольшой PDF документ, который в конкретные технологии не углубляется. И в нем написано, что согласно EE вам строго на строго не рекомендуется писать код вида new Thread().start();

Причина этого достаточно банальна. Контейнер создаёт кучу ThreadLocal для каждого потока и хранит там массу контекста. EM aka Unit Of Work имеет тот же жизненный цикл как и запрос-ответ. И каждый запрос использует свой собственный экземпляр EM. И как же серверу это удаётся? Именно через ThreadLocal. Когда вы создаёте свой собственный поток, то сервер понятия не имеет что к нему и как привязать.

Какая глубокая нужда вас заставила использовать Thread.start() - не понятно. Если вы уже используете JEE таймер, то он и так должен быть многопоточным и асинхронным к клиентским запросам. Какую задачу вы пытаетесь решить запустив асинхронный процесс внутри асинхронного процесса? Ну, если нужна какая-то в этом есть, то в JEE API есть и классы для запуска асинхронных задач. java.lang.Thread к ним не относится.

dymka,

https://docs.jboss.org/author/display/WFLY8/EJB3 subsystem configuration guide
Смотрите настройки Timer Service и его thread pool

dymka,

Вот ещё доступная статья
http://blog.chris-ritchie.com/2013/09/how-to-configure-scheduled-tasks-in-wildfly..html

dymka1. Собственно вопрос - можно делать такие таймауты? Или это не по "феншую"?

Какие такие? Зачем тут вообще таймаут?

dymka2. Или все же использовать ScheduleExecutorService?

Буква потерялась.
Вы таймер от таймаута не отличаете? ScheduledExecutorService имеет все те же проблемы в JEE что и ThreadStart. Если только вы его не создали средствами контейнера. Если его создаёт сам контейнер, то им, скорее всего, можно смело пользоваться.

dymka3. Если мне больше объект log не нужен - правильно делать detach?

Полагаю что "нет".

dymka4. И если все же произойдет повторный вход в timeout с истечением времени AccessTimeout, то можно ли каким-либо образом перехватить этот Exception?
Почему "повторный вход" вдруг должен вызывать исключение?

dymka5. И еще вопрос: если я в качестве Info таймера передаю сущность, то она приходит в таймер, но без объектов OneToMany. Они остаются неинициализированными. Поэтому в примере выше я передаю ID и заново делаю запрос. Это нормально?

Google -> JPA Lazy Initialization. Вообще это странно, что "с пустыми". Должно быть исключение ленивой инициализации.

dymka1, 4. Если оставить только @Timeout, то если будет запущена по расписанию вторая задача, в то время когда первая еще не закончилась, то выходит следующее:
Error invoking timeout for timer: ... javax.ejb.ConcurrentAccessTimeoutException

Это уже нюансы EJB. Если у вас Stateful бин или Singleton, то это вполне логично. EJB пытается обезопасить состояние от конкурентного доступа. А как на счет Stateless бина? Вообще у EJB так много подобных заморочек, что я бы сильно подумал перед тем как предпочесть JEE стэк Spring Framework-у.

dymka2. Именно, как заинжектенный компонент (@Resource), ибо, как понял, такие правила игры :). Но если будет работать вариант с TimerService и @Timeout - то это мне тоже не надо. Хочу как проще. TimerService так то идеально, если справлюсь.

Ну, тогда должно работать. Да.

dymka3. А что нужно сделать, чтобы объект был сохранен в БД, а потом из памяти удален. Т.е. убрать из управления EM. Ладно, сам покопаюсь еще.
Ну, как бы ничего не надо делать. EM надо закрыть. Но это контейнер должен сделать и сам при выходе из транзакции. Просто надо убедиться что EM закрывается.
А сам объект из памяти потом GC соберет. Это вообще отдельная тема.

dymka5. Да все верно, исключение при обращении к этим свойствам. Неверно выразился. Просто у этого объекта до таймера есть эти объекты, а в timeout они "пропадают" ). На данном этапе освоения технологии меня такие вещи просто обескураживают.
Ассоциации One2Many по-умолчанию грузятся лениво (отложено). Это надо знать. Это JPA и ORM с кучей подводных нюансов.
Ленивые ассоциации имеют внутри ссылку на сессию (EntityManager) и используют его чтобы загрузить зависимости, только тогда когда они действительно нужны. Если в одном потоке EntityManager закрыть (а контейнер это сделает сам по завершении транзакции), то в другом потоке догрузить ассоциации уже нельзя, так как EM закрыт.
Можно тупо передать ID и прогрузить объект заново. Все же кэш второго уровня решает.
Можно использовать Fetch и загрузить всё что нужно заранее - до закрытия EM. Тогда объект спокойно можно скормить в другой поток.

dymkaСпасибо большое, не хочу больше отнимать чужое время, буду разбираться с тем, что есть.
Раньше JEE был большим и сложным. Всё нужно было писать руками. Теперь писанины руками меньше, то зато всё большое и сложное осталось внутри скрытым от разработчика. Поэтому понять всё это очень сложно. Технологии очень жирные с кучей подобных нюансов. Но JPA надо изучать. Хороших альтернатив ORM-ам пока не видно.