в соответствии со спецификацией ejb 3.1, стр. 110, глава 4.8.5 «Одиночный параллелизм»:
Разрешено хранить объекты Java EE, которые не поддерживают одновременный доступ (например, менеджеры сущностей, ссылки на сессионный компонент с сохранением состояния) в состоянии экземпляра синглтон-компонента. Однако ответственность за обеспечение доступа к таким объектам не может быть получена более чем одним потоком одновременно.
и, более того, согласно документации Hibernate Entity Entity
EntityManager - это недорогой, не поддерживающий потоки объект, который следует использовать один раз для одного бизнес-процесса, одной единицы работы и затем отбрасывать.
Для меня это означает, что вы никогда не должны внедрять EntityManager в одноэлементный EJB. Я бы использовал одноэлементный EJB в качестве замены для EJB без состояния, только если ВСЕ, что мне нужно реализовать в этом классе, поддерживает параллелизм без необходимости дополнительной блокировки / синхронизации. Поскольку вы или другие программисты рано или поздно можете потерять эту проблему из-за вашего внимания, я лично предпочитаю не использовать одноэлементные EJB-компоненты, за исключением связанных с запуском проблем или функций, которые могут быть реализованы как автономные модули - независимо от других компонентов. В этом смысле кажется нецелесообразным вводить, например, EJB-объекты без состояния в синглтоны. При этом возникает вопрос о моменте времени, когда контейнер фактически выполняет инжекцию SLSB в синглтон? Согласно спецификации EJB 3.1, глава 4.8, внедрение зависимостей выполняется до того, как клиенты получат доступ к экземпляру синглтон-компонента. Таким образом, синглтон, очевидно, будет придерживаться одного и того же экземпляра SLSB, который, по-видимому, неявно становится одноэлементным, но, похоже, нет никаких гарантий для этого. По крайней мере, я не смог ничего найти в спецификациях, поэтому поведение может быть непредсказуемым или, в лучшем случае, специфичным для контейнера, а это не то, что нужно большинству людей.
Таким образом, я бы вводил синглтоны только в синглтоны или синглтоны в SLSB, но не наоборот. В случае внедрения Singleton в Singleton, Spec предлагает вам возможность определить зависимости между синглетонами, чтобы контейнер мог инициализировать их в правильном порядке (см. Спецификацию ejb 3.1, глава 4.8.1 относительно @DependsOn аннотация).