Зачем группируются безгражданные EJB?

В чем причина того, почему серверы приложений объединяют EJB без учета состояния?Зачем группируются безгражданные EJB?

Я могу понять, что полезно контролировать рабочую нагрузку приложения для входящих вызовов, но это только оправдывает объединение EJB, что сервер как FAÇADE с клиентом invoker.

Имеет ли какое-либо преимущество объединение внутренних EJB (те, которые не отображаются и только вызываются внутренне для выполнения бизнес-логики)? вместо использования общего отдельного экземпляра (например, Spring).

Я могу думать о по крайней мере одном недостатке: очень часто используемый внутренний EJB может действовать как узкое место.

источник

2012-01-16 edutesoy

Абоненты сеанса без учета состояния не обязательно являются потокобезопасными. Они могут хранить ресурсы, такие как сеансы JMS, которые не могут использоваться совместно более чем с одним потоком, поэтому сервер будет объединять их, чтобы он мог одновременно обслуживать несколько запросов для одного и того же компонента (ресурсы JMS также объединены, но я просто используя это для примера).

источник

2012-01-16 19:02:31 Dev

Если он не имеет гражданства, тогда не существует состояния, которому угрожает параллелизм, тогда никакие условия гонки не могут появиться, следовательно, они являются потокобезопасными, я не прав? Да, я знаю, что у них есть какое-то состояние, например, вложенные ресурсы, но тогда, возможно, их нельзя называть апатридом! :) Я отвечаю правильно. – edutesoy

@edutesoy Я согласен с вашим объяснением. Но почему государство поддерживается тогда. –

Я также хотел бы знать, почему объединенные EJB отсутствуют. Но я хочу знать, почему они объединены, а не создаются и уничтожаются по требованию. Тот факт, что экземпляры могут повторно использоваться для несвязанных запросов, значительно усложняет реализацию фагов без состояния (это означает, что вы должны быть невероятно осторожны в использовании полей экземпляра), и я не вижу в этом существенной выгоды.

В частности, я не вижу никаких преимуществ в области производительности. Я просунул реализацию фаз без апатии в JBoss (6, IIRC), и его единственный экземпляр компонента, который объединен; водопровод для обработки вызова метода воссоздается с нуля каждый раз, когда он используется. Это означает, что единственное сохранение производительности - это создание одного объекта, которое должно быть тривиальным временем. Единственная ситуация, в которой я вижу, что это нетривиальная, - это то, что bean приобретает тяжеловесные ресурсы и удерживает их между вызовами. Однако в этом случае компонент действительно используется как прославленный, плохо управляемый пул; правильным решением было бы объединение ресурсов напрямую!

Теперь EJB существует уже давно. Когда они впервые появились, создание объекта было дорогостоящим, поэтому было разумно объединить их. Но эти дни давно прошли. Почему в EJB3 не было сброшено объединение?

источник

2012-01-16 19:32:31

Ну, я полагаю, что если у вас есть тысячи одновременных запросов, имеет смысл объединить их или даже больше, чтобы создать их как @Singleton, если вы уверены, что они потокобезопасны, а не тысячи экземпляров в памяти. –

Если фаза является потокобезопасной, то да, синглтон идеален. Но если нет, загрузка памяти из пустых и выборочных экземпляров будет одинаковой; объединенные экземпляры фактически дадут сборщику мусора * больше * работу, потому что они живут достаточно долго, чтобы избежать питомника. –

Это большое утверждение. Я полагаю, это зависит от времени, которое требуется для каждого запроса, и поэтому время, которое эти объекты проводят в пуле. Если большинство из них можно использовать в любой момент времени, вы можете получить некоторую выгоду от создания/уничтожения. Это также зависит от тенденций движения и т. Д. Это очень слишком мелкозернистый анализ IMO :) –

Зачем группируются безгражданные EJB?

ответ

Смежные вопросы