... друзья... вообщем то я довольно опытный программист ... не первый год работаю... раньше так поверхностно сталивался с  EJB ... а тут решил наверстать пробелы в знаниях и занялся версий 3.0 

... никак не укладываеться в моей голове что такое этот Session Bean... чем стэйтфул от лэса отлечаеться... время жизни их.. .допустим в спринге было просто хочу синглтон пожалуйста... бин на сессию (и тут понятно что это веб сессия) пожалуйста... а в егб??? чем эти два вида бинов отличаються... как быть если мне нужен синглтон ( миграцию на версию 3,1 не предлогать :]]]])...  по каким идентификатором контейнер понимает что именно этот бин нужно мне вирнуть... или этот бин нужно в кэш засунуть... я уже перечитал спеку официальную но все равно какого то ощущения что я четко понимаю эти вещи нету...

... плиззз хелп... обьясните

Чтайте доки, там всё расписано - http://download.oracle.com/javaee/6/tutorial/doc/gipjg.html
С веб-сессиями сессионные EJB не связаны.
Для связи сессионных EJB с веб-сессиями есть Seam, а в java ee 6 есть CDI.

Синглтона в 3 нет. Если нужен синглтон в 3 - то можно юзать специфичные фичи AS, например @Service у JBoss.

sith, 

Сессия создается для клиента. Только клиент не всмысле - посетитель сайта, а программа этот бин у апликейшен сервера запрашивающая.

Т.е. запустили Вы Web приложение - для него создался один бин, запустили другое вебприложение - для него другой бин. Запустили SE приложение и обратились к бину на сервере - для него создан 3 бин. 

Получить ссылку на бин можно двумя путями, через DI и через JNDI.

Stateful бины инжектить не стоит, так как при каждом инжекте мы имеем ссылку на новый instance.

Пример инжекта stateless-бина:

@EJB
private MyBean myBean;

myBean.myMethod1(...);
myBean.myMethod2(...);


поскольку это stateless-бин - методы 1 и 2 могут быть вызваны для разных instance, какой instance будет под рукой (в пуле) ближе - тот и будет использован.

В случае stateful-бина (ссылку на него следует полчить через jndi lookup) методы будут вызваны для одного и того же инстанса.


Стало понятней?

понятнее но не все...

... как контейнер понимает что запрос пришел из разных клиентов... допустим с вебом понятно... туда возвращаеться id сессии... а тут как???...

... дальше клиент это что... отдельный джарник... или это только веб приложения... ??? 

... если инжектить нерекомендованно то зачем тогда вообще есть возможность эта для стэйтфул бинов. как то это не очень... наверно что в одном месте инжектим а вот тут не рекомендуеться и мне нужно постоянно делать лукап нужного бина...


... пример... допустим есть приложение под кодовым названием  "ведро-1"... есть бин стэйтфул ... бин хранит некий обьект ведро и есть бизнес метод по заполнению этого ведра. получаеться если различные пользователи этого приложения будут вызывать этот метод они все будут работать с одним ведром и заполнять одно ведро.... если будет запущенно два приложения "ведро-1" то укаждых пользователей будет по своему ведру??? 

... 

хранится некий контекст сессии, неважно как это реализуется в протоколе.


Это может быть клиент внутри сервера приложений, а может быть отдельное приложение на свингах, например.


почему постоянно? когда нужен новый инстанс, тогда и лукапим.
ЗЫ: стейтфул бины используются РЕДКО.


Не так. Это никак не зависит от приложения.

Ещё раз повторю - при КАЖДОМ лукапе мы получаем НОВЫЙ ИНСТАНС стейтфул бина.

MyBean b = (MyBean)ctx.lookup("MyBean/remote");
b.putOrder(...);
b.putOrder(...);
b.countOrders();

Т.е. здесь вызов методов произойдёт как будто MyBean - обычный класс. Вот примерно как если бы вместо (MyBean)ctx.lookup("MyBean/remote"); тут был new MyBean();, с той лишь разницей что методы отработают на сервере, а не локально.

А если бы MyBean был стейтлесс - то все вызовы методов были бы направлены на произвольные инстансы из пула.

так... подожди 



так при инжекте или лукапе будет создаваться новый инстанс?... если я в классе своем пижу анатацию @EJB ... создасться новый или вызоветься старый...


... конкурентный доступ к стэйтфул бинам - я так понимаю что эти бины могут иметь внутренние поля... контейнер обеспечивает конкурентный доступ или это все ложиться на мои хрупкие плечи???


зачем иметь милион стэйтлесс бинов если они не гарантируют состояние обьекта а значит имеют только сервисные методы... почему не сделать один синглтон... для всех обращений???

Именно.


посмотрите тут, например - http://forums.java.net/jive/thread.jspa?threadID=13439


конкурентный доступ имеет смысл для синглтона, при работе же со стэйтфул бином работа с ним идёт в том же треде, в котором был лукап, а по каждому лукапу создаётся отдельный инстанс.


Потому что стэйтлесс бины работают очень быстро и легко масштабируются и кластеризуются. Состояние же следует хранить в БД, например.




Может быть вы пытаетесь взвалить на Stateful бины ту задачу что выполняют Entity?

... что именно?... я понимаю инжект это когда я имею переменную в классе и всовываю в нее значение бина по средством анотации @EJB  - при этом будет новый бин или уже до этого созданный???


...



и все же... к примеру есть инстанс сервиса А у которого есть бизнес метод перевестиНаАнглийский - зачем контейнеру создавать 2,3 милион обьектов... если у этого инстанса нет состояния... и мето вызванный что у одного... что у двух инстансов будет будет выполнять тоже самое... в чем при рост... чем это отличаеться от бычного сервисного синглтона который отдаеться всем кто попросит... в чем приемущества???

какие нибудь мысли еще???

Не путайте statefull и stateless
stateless - не обязательно будет создавать новый инстанс, может быть использован уже существующий.
Кол-вом инстансов управляет контейнер.
statefull - даёт гарантию работы с одним и тем же инстансом

Посмотрите EJB 3 in action - сразу тьма вопросов отпадёт

Это сообщение отредактировал(а) stron - 29.10.2010, 16:57

ну а зачем для стэйтлесс вообще разные инстансы?

Ну это же очевидно!
Имеется пул инстансов, так что запрос от клиента отрабатывает на первом свободном инстансе. Это гарантирует, что в момент вызова бизнес-метода только один клиент (тред) использует стейтлесс-бин, т.е. не нужно никакой синхронизации и конкурентности, накладные расходы минимальные. А поскольку все инстансы одинаковые - то они легко масштабируются и запросы могут направляться на любую машину из кластера.

Это вроде как даже само понятно, но можно и книжки почитать, "EJB3 in Action" - то что надо.

а какие проблемы конкурентности и синхронизации если стэйтлес бин не гарантирует сохранение состояния... если его используют как сервисную заглушку... какие разделяемые ресурсы юзает стэйтлес бин... да и кто зная его спицифику будет всовывать подобные ресурсы в него?

Его используют для реализации бизнес-методов.