Вообще-то не рекомендуют потоки и сокеты в EJB использовать.
Когда-то надо было сделать ServerSocket так сделали на JMX.

wessen...Или вместо потока использовать ejb timer service?

Да, самое то.
Можно ещё JMS попробовать, если подойдёт. Подумайте может задача укладывается в несколько очередей.

wessenНе совсем понятно, чего хотели сантехники сказать этим предложением - Multithreaded applications are still possible, but control of multithreading is located in the container, not in the enterprise bean.
Вот нашёл в спецификации EJB3
21.1.2 Programming Restrictions
• The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise
bean must not attempt to manage thread groups.
These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads
would decrease the container’s ability to properly manage the runtime environment.

wessenГде-то читал, что так же нельзя делать синхронизированными бизнес методы. А как EJB контейнер переносит синхронизированные блоки в бизнес методах? Причем блоки синхронизируются по static final полю.
Всё там же пишут:
21.1.2 Programming Restrictions
• An enterprise bean must not use read/write static fields. Using read-only static fields is
allowed. Therefore, it is recommended that all static fields in the enterprise bean class be
declared as final.
This rule is required to ensure consistent runtime semantics because while some EJB containers may
use a single JVM to execute all enterprise bean’s instances, others may distribute the instances across
multiple JVMs.
• An enterprise bean must not use thread synchronization primitives to synchronize execution of
multiple instances.
This is for the same reason as above. Synchronization would not work if the EJB container distributed
enterprise bean’s instances across multiple JVMs.

Так что Вы, похоже, всё что можно нарушили :)

wessenНа счет синхронизации не все так просто. Вот например - http://www.theserverside.com/discussions/thread.tss?thread_id=25383

Как я понял, синхронизировать можно, только не все подряд и осторожно.

И даже если своими мозгами пораскинуть, без ссылок на спецификации и блоги бывалых программеров - есть у меня сессион бин, в нем используется большое кол-во библиотек, как стандартных, так и сторонних, в итоге, одних импортов на 70 строк. И неужели не одна из этих библиотек не содержит синхронизированных блоков и методов? Конечно содержат, банально, тот же SynchronizedHashMap. И более того, наверника эти библиотеки создают потоки и не один. Так-что запутано все как-то...

Ну и попробуйте сделать с JMS.
Будет всё правильно и красиво.

wessen Blazkowicz wessenЕсли использовать JMS, что будет из себя представлять временное хранилище?

Очередь сообщений.

С очередями я работал через Message Driven Bean и на сколько я знаю, как только в очередь попадает сообщение, сразу же создается экземпляр MDB и внем я получаю сообщение. Так а хранить сообщения где тогда? Или очередь можно настроить так, чтобы сообщения в ней накапливались, а потом их можно получить пачкой получить?

Хранятся сообщения в очереди, причём при выключении сервера записываются в постоянное хранилище и потом не пропадают.
Забирать их оттуда необязательно с помощью MDB, можно написать внешнюю программу( или несколько). Правда забираются они оттуда по одному, но есть способы просмотра очереди и анализа содержимого без изъятия сообщений из неё.