|
|
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Вот такой клиент: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Вот такой Session Bean: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Запускаю GlassFish - на нём Session Bean работает. Запускаю 2 разных клиента на разных компах (1 виртуальный, а другой реальный) - 1 клиент видит то, что в переменную debug_str (которая на сервере), написал другой клиент. Почему так? @Stateless не должен сохранять своё состояние между вызовами. А он ведёт себя как @Singleton. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 10:10:15 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000 @Stateless не должен сохранять своё состояние между вызовами. А он ведёт себя как @Singleton. Маленькая поправка, контейнер не гарантирует что вы будете получать всегда один и тот-же бин. У вас так получилось что два клиента получили в разное время один и тот же бин и это нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 10:28:30 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
А если мне хочется получить точно 2 разных SessionBean, то что делать? Если хочется получить ссылки на 1 и тот же SessionBean, то его надо объявить @Singleton и он будет существовать в единственном экземпляре в пределах всего сервера. Это понятно. А если надо так: Сколько экземпляров клиентов - столько разных экземпляров SessionBean'ов. А какой смысл тогда в этих аннотациях если контейнер не гарантирует то, что @Stateless будет @Stateless? Я тогда вообще не вижу разницы между @Stateless, @Stateful и @Singleton - ведут они себя одинаково. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 10:36:36 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000, Есть такая штука как пул ejb объектов, так вот пре старте(deploy) какого либа stateless bean. Контейнер создать несколько инстансов и будет вам их выдавать по мере требования. Взаимодействие происходит через прокси объекты и каждый раз вам выдает разные инстансты при каждом новом вызове метода бина. Со stateful бин работа идет немного иначе, когда вы получили прокси объект на него , вызываемы методы этого бина всегда будут передаваться одному и тому же инстансу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 10:46:24 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000, Контейнер также гарантирует что один клиент работает всегда с одним бином, поэтому ejb beans thread-safe. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 10:49:09 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000Я тогда вообще не вижу разницы между @Stateless, @Stateful - ведут они себя одинаково.нет stateless может хранить состояние и "шарить" его между разными клиентами. об этом сказано вообще-то. но это "шарить" не гарантируется. Niky4000А если мне хочется получить точно 2 разных SessionBean, то что делать?использовать stateful, не? Niky4000@Stateless не должен сохранять своё состояние между вызовамиstateless хранит своё состояние. stateful хранит состояние для клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 10:53:00 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
GregTkВзаимодействие происходит через прокси объекты и каждый раз вам выдает разные инстансты при каждом новом вызове метода бина.нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 10:53:47 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
stateless может хранить состояние и "шарить" его между разными клиентами. об этом сказано вообще-то. но это "шарить" не гарантируется. Мне надо бы 2 случая: 1 Чтобы "шарить" между клиентами было - тогда я использую @Singleton. 2 Чтобы никакого "шарить" между клиентами не было никоим образом - тогда получает мне нужен @Stateful (ещё не проверил это). А зачем тогда нужен @Stateless не понятно, если я точно не знаю будет ли он разделён между клиентами или нет, сохранит он своё состояние после того как его поиспользовал другой клиент или нет и т.д.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 11:04:20 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000stateless может хранить состояние и "шарить" его между разными клиентами. об этом сказано вообще-то. но это "шарить" не гарантируется. Мне надо бы 2 случая: 1 Чтобы "шарить" между клиентами было - тогда я использую @Singleton. 2 Чтобы никакого "шарить" между клиентами не было никоим образом - тогда получает мне нужен @Stateful (ещё не проверил это). А зачем тогда нужен @Stateless не понятно, если я точно не знаю будет ли он разделён между клиентами или нет, сохранит он своё состояние после того как его поиспользовал другой клиент или нет и т.д.? ещё раз ) stateless хранит (может сохранить, и клиент это может узнать, но не гарантируется) своё состояние. stateful хранит состояние для клиента. http://docs.oracle.com/javaee/6/tutorial/doc/gipjg.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 11:09:34 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Кстати, сейчас проверил эту теорию с @Stateful - вроде работает как надо - один клиент пишет что-то в текстовую переменную, а другой не видит что при этом первый написал туда. Если я объявлю SessionBean как @Singleton - то получается то, что мне надо - второй случай - данные клиентов в переменных пересекаются. А зачем нужен @Stateless, если непонятно как он работает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 11:09:48 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000 А зачем нужен @Stateless, если непонятно как он работает? даже ссылка на jee6 tutorial не объясняет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 11:13:20 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Я сейчас просто с этим столкнулся... И я перестал понимать зачем нужен @Stateless, а везде пишут, что @Stateless используется повсемесно, а @Stateful почти не используется, а @Singleton - это новинка в EJB3, раньше его не было. Я раньше думал, что @Stateless - это когда состояние не сохраняется и с ним несколько клиентов могут работать, никак не взаимодействуя друг с другом. А сейчас у меня Мир перевернулся - оказывается это не так, да к тому же не понятно (не гарантируется контейнером) что за Session Bean я получаю - новый чистенький или тот, который поимел другой клиент, то ли они shared между клиентами, то ли не shared - это тоже не гарантируется контейнером. Я вот это не понимаю. Сейчас ссылочку почитаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 11:17:06 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
То что вы добавляете состояние в Stateless это ваши личные проблемы. Он сделан для того чтобы не хранить состояния. А гарантирует он лишь то что два параллельных клиента не будут использовать один и тот же экземпляр. Должен согласиться что всё это не логично и не очевидно, как и весь EJB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 11:20:25 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Как я понял @Stateless берутся из пула - их там может быть несколько. Какой Session Bean будет использоваться каким клиентом решает контейнер. Может так получиться что 1 и тот же @Stateless Session Bean могут поиспользовать 2 разных клиента, а 3-й клиент может получить не тот же самый Session Bean, что первые 2 клиента. Соответственно если рассматривать Web - то там @Stateless Session Bean эффективнее, чем @Staful Session Bean, так как меньше нагружают сервер. Число @Stateless Session Bean может быть меньше числа клиентов, а в случае с @Staful Session Bean, их число = числу клиентов. @Singleton cуществует в единственном экземпляре в пределах всего сервера и очищают своё состояние только если сервер перезагрузился или грохнулся. Я вот только не очень понял: A stateless session bean can implement a web service, but a stateful session bean cannot. ... Like stateless session beans, singleton session beans can implement web service endpoints. Stateless session beans и singleton session beans могут реализовать web-сервес, а stateful не может. Почему? Если у нас на 1 клиента 1 stateful, почему нельзя? Типа stateless берётся из пула и их число меньше числа пользователей, а stateful = числу пользователей, как бы менее эффективно расходуется память. Или что? Я вот этот момент как-то не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 11:46:21 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
экземпляр stateful привязывается к единственному клиенту. Спека Web Service почти полнотью stateless. Она не подразумевает никаких "сессий" с клиентом. Поэтому никакого смысла использовать stateful для Web Service нет - нет никаких стандартов для этого. HTTP сам по себе тоже stateless. jsessionid это уже отсебятина сервлетов. Web Service даже не обязательно должен работать по HTTP. Cходу даже не гуглиться какая-нибудь w3c спека для сессия в Web Service. Поэтому если вам нужно явно связывать Web Service и сессии, это приходится делать руками, так как механизмы поддержки сессии не стандартизированы и у всех разные. Например те же куки поддерживаются браузерами, а не толстыми клиентами. Поэтому делать сессии на jsessionid тоже особого смысла нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 12:08:59 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000, Расскажу про веб-сервисы. Тут есть много вариантов. С одной стороны stateful бин не может реализовывать web-service потому что вебсервисы по природе stateless - они не сохраняют состояние, они содержат операции. И еще, нет возможности определить от одного и того же клиента пришло два вызова вебсервиса или от разных. Поэтому не понятно, какой экземпляр stateful бина должен принимать вызов. Но, строго говоря, это не совсем так. Вы можете в soap передавать руками sessionid и таким образом определять клиента - но это кустарный способ, statful bean тут не подключить, так как контейнер не знает, откуда брать тот sessionid, чтобы определить клиента и соответственно подсунуть ему тот или иной stateful bean. И опять же - используя WS-Addressing можно и stateful бин использовать как ws-endpoint, так как WS-Addressing позволяет определять клиентов (погуглите на эту тему и вы найдете). Или же так - если вы уверены что у вас вебсервисы будут работать только по http, а в большинстве ситуаций так и бывает, то можно использовать стандартный JSESSIONID, который приходит в http headers запроса. И в этом случае вы можете использовать stateless bean как ws-endpoint и в него инжектить CDI SessionScoped bean или RequestScoped bean - контейнер будет инжектить инстансы относящиеся к вызываемому клиенту (клиента он определит по JSESSIONID в http headers) Ох, надеюсь понятно что я тут написал, спешил я. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 12:16:03 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
rabiterОх, надеюсь понятно что я тут написал, спешил я. Всё верно. Сессии в Web Service не стандартизированы. Поэтому дефолтной реализации нет. Но бюбую кустарную сделать не сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 12:17:48 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
rabiter, Если не сложно, подскажите, пожалуйста каким боком тут WS-Addressing? Это через replyto что ли сессию трекать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 12:19:49 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Blazkowiczrabiter, Если не сложно, подскажите, пожалуйста каким боком тут WS-Addressing? Это через replyto что ли сессию трекать? На практике с WS-Addressing не работал. Но как я понял, этот фреймворк позволяет идентифицировать узлы. Таким образом можно определить от какого конкретно клиента пришел запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 12:27:14 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Хотя, может я поспешил с выводами. Узел-то определить WS-Addressing может и позволяет, но самого вызываемого, под вопросом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 12:37:36 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Stateful удобно использовать в Application Client'ах. Но если надо будет потом в перспективе прикрутить параллельно ещё и Web модуль, который был бы тонким клиентом, то получается, что не не может использовать те же Stateful Session Bean'ы, что и Application Client. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 13:26:18 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000Stateful удобно использовать в Application Client'ах. Но если надо будет потом в перспективе прикрутить параллельно ещё и Web модуль, который был бы тонким клиентом, то получается, что не не может использовать те же Stateful Session Bean'ы, что и Application Client. Может, но HTTPSession и Stateful bean нужно будет подружить руками. Сам сервер этого не делает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 13:33:53 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000Stateful удобно использовать в Application Client'ах. Но если надо будет потом в перспективе прикрутить параллельно ещё и Web модуль, который был бы тонким клиентом, то получается, что не не может использовать те же Stateful Session Bean'ы, что и Application Client. Не хотите попробовать в Application Client'ах использовать CDI бины? Мы вообще отказались от EJB бинов в пользу CDI. CDI бины и с HTTPSession хорошо дружат в отличии от stateful. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 14:08:10 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Кто такие CDI бины? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 14:08:46 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
BlazkowiczКто такие CDI бины? Те, что управляются контейнером специфицированным JSR-299. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 14:39:02 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
rabiterТе, что управляются контейнером специфицированным JSR-299. Там написано что технология должна помочь подружить JSF и EJB. Иногда обзывается Web Bean. Но CDI-bean это вообще любой проинжекченый бин, в том числе @EJB. Осталось понять что вы с Niky4000 подразумеваетет под Application Client. Где и stateful удобен и CDI работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 14:48:26 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
grasoff.net, а как тогда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 14:55:35 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
BlazkowiczrabiterТе, что управляются контейнером специфицированным JSR-299. Там написано что технология должна помочь подружить JSF и EJB. Иногда обзывается Web Bean. Но CDI-bean это вообще любой проинжекченый бин, в том числе @EJB. Осталось понять что вы с Niky4000 подразумеваетет под Application Client. Где и stateful удобен и CDI работает. Понять-то думаю не сложно. Application client я так понял это desktop имеется ввиду? Толстый клиент? По поводу JSF и CDI - в JSF сейчас рекомендуют использовать CDI вместо JSF Managed Beans например: javax.enterprise.context.SessionScoped вместо javax.faces.bean.SessionScoped. Это да. Но не одним JSF ограничено применение CDI. Вот вы например, работаете со спрингом, и конечно же, используете все радости его IoC? В том числе и длительность жизни бинов (session, request, singleton, prototype, какие там еще есть...). А что нам делать если мы спринг не используем? IoC-то тоже охота. Так вот CDI это в какой-то мере тоже самое, только специфицировано в JavaEE. Имплементация от JBoss Weld. Вещь хорошая, мне понравилась очень как разобрался. Включает в себя например Annotated Qualifiers - т.е. с помощью аннотации мы можем контейнеру указать какую конкретную из имплементаций требуется заинжектить. Продюссеры - методы, которые позволяют написать свой код, решающий какой инстанс будет заинжекчен. И еще много другого. Отлично работает с web. Но и не только, с desktop тоже. И еще, EJB и CDI путать не стоит, тот же класс синглетон есть и в EJB и в CDI: javax.ejb.Singleton - EJB3.1 javax.inject.Singleton - CDI Первый управляется контейнером EJB, второй - CDI. И аннотация @Inject относится к CDI бинам, а @EJB - соответственно к EJB. Так с помощью @Inject заинжектить EJB бин нельзя (хотя это легко обойти с помощью продюссеров). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 15:09:33 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Понять-то думаю не сложно. Application client я так понял это desktop имеется ввиду? Толстый клиент? Ну, да. Продюссеры - методы, которые позволяют написать свой код, решающий какой инстанс будет заинжекчен. И еще много другого. Отлично работает с web. Но и не только, с desktop тоже. То есть какой экземпляр @Singleton'а отдать в пользование в какую сессию? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 15:37:12 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
rabiterрекомендуют использовать CDI вместо JSF Managed Beans И еще, EJB и CDI путать не стоит Т.е. CDI-бины это обычные POJO, жизненым циклом которых контейнер умеет управлять, но ни к EJB, ни к Managed Bean они вообще никак не относятся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 15:44:29 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Blazkowiczrabiterрекомендуют использовать CDI вместо JSF Managed Beans И еще, EJB и CDI путать не стоит Т.е. CDI-бины это обычные POJO, жизненым циклом которых контейнер умеет управлять, но ни к EJB, ни к Managed Bean они вообще никак не относятся? Ну да. Они могут заменить JSF Managed бины. С помощью аннотации @Named CDI бину можно указать строковое имя, через которое потом к нему можно в файслетах обращаться. Единственная проблема - в JSF есть ViewScoped, в CDI такого нет. Но это обходится с помощью ConversationScoped. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:22:21 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Я тут размышляю над всем этим... Пока CDI не рассматриваю. Ну, допустим мы будем использовать Stateless, так как существует их Pool и они могут более эффективно обрабатывать web-запросы, чем Singleton'ы. А как быть, например, с фабрикой фабрик - такая штука, которая позволяет легко переключаться с одного набора Session Bean'ов на другой, например, в целях отладки. Она какого типа должна быть при условии, что она возвращает Stateless Session Bean'ы? Тоже Stateless? Или неважно какого типа? А если она будет Singleton, то и то что она возвращает тоже, наверное, будет фактически Singleton? Поясню сказанное на примере, а то вдруг не понятно. Пример: Session Bean, который возвращается фабрикой фабрик является Stateless, а сама фабрика фабрик у нас Singleton, то получается, что фабрика фабрик будет возвращать один и тот же экземпляр Session Bean'а, несмотря что есть их пул. По сути она будет возвращать Singleton. Или нет? Если это так, то поможет ли объявление фабрики фабрик в качестве Stateless? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:22:50 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
rabiterНу да. Они могут заменить JSF Managed бины. С помощью аннотации @Named CDI бину можно указать строковое имя, через которое потом к нему можно в файслетах обращаться. Единственная проблема - в JSF есть ViewScoped, в CDI такого нет. Но это обходится с помощью ConversationScoped. Мда. Как JEE ни стремиться к простоте, простота для неё не достижима. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:25:05 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000Понять-то думаю не сложно. Application client я так понял это desktop имеется ввиду? Толстый клиент? Ну, да. Продюссеры - методы, которые позволяют написать свой код, решающий какой инстанс будет заинжекчен. И еще много другого. Отлично работает с web. Но и не только, с desktop тоже. То есть какой экземпляр @Singleton'а отдать в пользование в какую сессию? Не только синглетона, это может быть sessionscoped и requestscoped бин. Фишка в том, что с помощью продюссера вы можете реализовать какую-нибудь логику, которая принимает решение какой экземпляр бина должен быть заинжекчен. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ну и далее в коде получаем доступ к IntegrationService: Код: java 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:30:39 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
BlazkowiczrabiterНу да. Они могут заменить JSF Managed бины. С помощью аннотации @Named CDI бину можно указать строковое имя, через которое потом к нему можно в файслетах обращаться. Единственная проблема - в JSF есть ViewScoped, в CDI такого нет. Но это обходится с помощью ConversationScoped. Мда. Как JEE ни стремиться к простоте, простота для неё не достижима. Аминь, сплю и вижу спринг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:31:19 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
То есть какой экземпляр @Singleton'а отдать в пользование в какую сессию? Опечатался. У Singleton'а 1 экземпляр. Я тут имел ввиду экземпляр Stateless - их же много типа и они в пуле находятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:37:58 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
А всё-таки как быть с фабрикой фабрик? И ещё, если мы создаём EntityManagerFactory и EntityManager'ы в Singleton'е, то тот клиент, который первый захватил ресурс и будет им пользоваться, а другие будут ждать. То есть соединение с СУБД тоже как бы Singleton получается, если можно так выразиться. А если пул соединений захочется сделать, то надо List<EntityManagerFactory> и List<EntityManager> делать? И как-то определять какой em занят, а какой нет? То есть пулом ручками рулить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:51:29 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Я полагаю сервер не даст инжектить EntityManager в Singleton. А для нормального конкуретного доступа достаточно заинжектить EntityManagerFactory и для каждого потока получать EntityManager в локальную переменную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:55:07 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000А всё-таки как быть с фабрикой фабрик? И ещё, если мы создаём EntityManagerFactory и EntityManager'ы в Singleton'е, то тот клиент, который первый захватил ресурс и будет им пользоваться, а другие будут ждать. То есть соединение с СУБД тоже как бы Singleton получается, если можно так выразиться. А если пул соединений захочется сделать, то надо List<EntityManagerFactory> и List<EntityManager> делать? И как-то определять какой em занят, а какой нет? То есть пулом ручками рулить? Пул соединений к базе реализовывать не надо. Все уже реализовано до нас. Возьмите с Apache Commons, или готовый реализованный в ApplicationServer'е. Потокобезопасностью синглетона можно управлять, в частности, с помощью аннотации LockType. Если поместите синглетон в критическую секцию, то он будет потокобезопасным, но может стать и бутылочным горлышком. Где будут ждать куча клиентов своей очереди выполнить код синглетона для своего потока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 16:59:05 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Я полагаю сервер не даст инжектить EntityManager в Singleton. А для нормального конкуретного доступа достаточно заинжектить EntityManagerFactory и для каждого потока получать EntityManager в локальную переменную. Да не, он даёт. Вот я и думаю над доступом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:03:19 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000Да не, он даёт. Вот я и думаю над доступом... Ну и в чем проблема? инжектим EntityManagerFactory через CDI, в методах делаем em = factory.getEntityManager() и в finally блоке закрываем. try-with-resources, интересно, поддерживается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:09:38 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
авторЯ полагаю сервер не даст инжектить EntityManager в Singleton. А для нормального конкуретного доступа достаточно заинжектить EntityManagerFactory и для каждого потока получать EntityManager в локальную переменную. Когда мы создаём EntityManagerFactory - то это и есть установка соединения с СУБД. В момент создания мы передаём такие параметры, как user, password, url... Под пулом соединений я понимаю List<EntityManagerFactory>. Ну, если ручками. авторПотокобезопасностью синглетона можно управлять, в частности, с помощью аннотации LockType. А у нас ничего плохого не происходит если 2 потока борются за 1 EntityManager. Просто 1 пользуется, а другой ждёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:11:37 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Ну и в чем проблема? инжектим EntityManagerFactory через CDI, в методах делаем em = factory.getEntityManager() и в finally блоке закрываем. try-with-resources, интересно, поддерживается? А может быть создать некое количество соединений в Singleton'е и выдавать свободные? И соединения не закрывать, так как открытие/закрытие соединений - процесс ресурсоёмкий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:14:33 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000Когда мы создаём EntityManagerFactory - то это и есть установка соединения с СУБД. Нет, это не есть "установка соединения с СУБД". Niky4000 В момент создания мы передаём такие параметры, как user, password, url... Это у вас в DataSource должно быть прописано. Niky4000Под пулом соединений я понимаю List<EntityManagerFactory>. Зачем? авторА у нас ничего плохого не происходит если 2 потока борются за 1 EntityManager. Просто 1 пользуется, а другой ждёт. Ну, т.е. выстроить всех клиентов в очередь, это по-вашему, нормально? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:15:56 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000А может быть создать некое количество соединений в Singleton'е и выдавать свободные? И соединения не закрывать, так как открытие/закрытие соединений - процесс ресурсоёмкий. Чего вы к соединениям пристали? Ими пусть DataSource занимается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:16:44 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Нет, это не есть "установка соединения с СУБД". А что это такое? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:31:12 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Niky4000А что это такое? Это ужас. :) Создаётся EMF с неким внутреним пулом. Так никто не делает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 17:33:00 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
properties.put("eclipselink.jdbc.connections.initial", "1"); properties.put("eclipselink.jdbc.connections.min", "1"); properties.put("eclipselink.jdbc.connections.max", "4"); А чего тут плохого? Вот определяю размеры пула. И рулю им ручками. Можно конечно использовать Conteiner Management EntityManager - там пулом рулит контейнер, а его размеры опредяляются настройками сервера. Но там тип ресурса JTA, а с JTA нельзя в явном виде управлять транзакциями. Вот я и создаю свой EMF - определяю динамически пул, и сам управляю транзакциями и соединениями. Это ужас. :) Создаётся EMF с неким внутреним пулом. Так никто не делает. А как делают? В данном случае я могу явно определить к какому СУБД подключаться. Мне нужно в явном виде управлять транзакциями Entity Manager'а. Когда что commit'ить или rollback'ить, так как Conteiner Management EntityManager сам как-то там решает когда ему commit'ить или rollback'ить и часто это неудобно, так как ожидая увидеть данные в таблице, оказывается что там их нет - неза'commit'чены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2012, 21:40:28 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Соединение создаётся не при создании EMF, а при создании EM. Причём как ни верти-крути: создание нескольких экземпляров EMF или EM от разных EMF - всё равно клиенты выстраиваются в очередь. А физически соединение, видимо, одно получается и все через него ходят на запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2012, 10:07:39 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
Нужно создать нормальный JNDI DataSource в сервере и его использовать из приложения. Это в будущем вам сэкономит массу времени при командной разработке и деплойменте на разные сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2012, 11:31:33 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
авторНужно создать нормальный JNDI DataSource в сервере и его использовать из приложения. Это в будущем вам сэкономит массу времени при командной разработке и деплойменте на разные сервера. Это есть тоже. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. А ещё нужно соединение, которое можно конфигурировать "на лету". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2012, 15:00:19 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
DataSource не нужно никуда инжектить, если вы не собираетесь работать на прямую с JDBC. Нужно чтобы ваш Persistence Unit использовал его, а не JDBC настройки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2012, 15:46:50 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
GregTkgrasoff.net, а как тогда?ну.. вот даже автор пишет прямо противоположное ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2012, 19:48:02 |
|
||
|
@Stateless Session Bean работает как @Singleton почему-то...
|
|||
|---|---|---|---|
|
#18+
GregTkСо stateful бин работа идет немного иначе, когда вы получили прокси объект на него , вызываемы методы этого бина всегда будут передаваться одному и тому же инстансу.тоже не совсем верно. клиент получит одно и то же (с точки зрения свойств удалённого stateful) состояние удалённого сервиса. но это не значит, что в контейнере это будет тот же (this == that) инстанс ) я так, к словам придираюсь ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2012, 19:50:16 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2131451]: |
0ms |
get settings: |
19ms |
get forum list: |
31ms |
check forum access: |
9ms |
check topic access: |
9ms |
track hit: |
76ms |
get topic data: |
24ms |
get forum data: |
7ms |
get page messages: |
142ms |
get tp. blocked users: |
3ms |
| others: | 349ms |
| total: | 669ms |

| 0 / 0 |
