Действительно, существует только один экземпляр для конкретного Servlet, поскольку предполагается, что он не имеет состояния. На практике это не всегда так, но так и будет.
Однако существует несколько экземпляров Stateless session beans (SLSB), и они объединяются.
По определению stateless session beans не имеют состояния, поэтому на первый взгляд это кажется парадоксом. Дело в том, что, хотя stateless session beans не имеют статуса в отношении индивидуальных звонков, которые они им совершают, на самом деле они очень часто имеют состояние.
Это состояние имеет вид ссылок на другие ресурсы . JPA entity manager, который не потокобезопасен, является ярким примером здесь. Во время одного вызова stateless session bean вызывающий должен иметь эксклюзивный доступ к этому ресурсу. Когда звонок возвращается, следующий абонент может иметь эксклюзивный доступ и т. Д.
Если бы использовался один экземпляр, то либо все вызывающие абоненты должны были бы ждать друг друга (что, конечно, снижает производительность), либо они имели бы доступ к этому единственному экземпляру одновременно. В последнем случае разработчик компонента должен выполнить ручную блокировку не поточно-ориентированных ресурсов, таких как entity manager, который часто хрупок, подвержен ошибкам и, в конце концов, заставляет абонентов ждать друг друга.
Таким образом, чтобы улучшить производительность и при этом иметь гарантию безопасности, используются несколько экземпляров.
Эти экземпляры затем объединяются и используются повторно, а не создаются заново для каждого запроса, поскольку поиск, инициализация и внедрение всех необходимых зависимостей компонента могут потенциально занимать много времени.
Таким образом, все это автоматически также означает, что если вы внедрите менеджер сущностей или другой не поточно-ориентированный ресурс в сервлет (что разрешено), у вас могут возникнуть проблемы. Это небольшая лазейка в архитектуре Java EE, которую, конечно, легко обойти, просто используя сессионные компоненты без сохранения состояния.