Здрасти всем.

Продолжая мучать JBoss и себя:

Есть бин, который имеет ссылку на другой бин. Из клиентской проги надо достучаться до первого бина, а через него до второго.
Клиент и JBoss в разных JVM, т.е. как я понимаю через Container Managed Relationship это не реализовать из-за 
необходимости использования локальных интерфейсов.
    Я пошёл другим путём - использую удалённые интерфейсы - всё работает, но на поиск компонента (получение домашнего интерфейса) 
уходит много времени. Компонентов может быть очень много, и каждый раз осуществлять поиск накладно. 
Отсюда вопрос:
  Можно ли как-то кэшировать ссылки на домашние интерфейсы компонент для доступа к ним из других бинов?

Добавлено через 3 минуты и 9 секунд
да, забыл про тему:

я думаю что можно хранить ссылки в EntityContext.getEnvironment()

но когда я вызываю этот метод из бина - вылетает ошибка EJBException Deprecated

Может попробовать сделать их SessionFull ? ТОгда по идее они должны быстрее подниматься.
А по поводу хранения ссылки - надо почитать - где-то я такое смотрел. Если найду - напишу

конечно можно было бы сделать так:

 Entity Bean будут лиш отображением строк в таблице БД,
 А всю логику отношений между этими бинами реализовать в Session Bean.

Но мне как-то не нравится этот способ - некрасиво получается.

Я уж даже и не знаю: если не получится, то придётся писать используя чистый RMI, 
хотя идея EJB очень привлекательна.

Т.е. в stateless или stateful-бине (клиенте) инкапсулируется логика поиска связанного с основным дочернего entity-бина? Да, так можно делать и частенько такие решения встречаются. Но это неудобно, т.к. усложняется код клиента для entity-бинов. Лучше пользоваться cmr (relations).


надо кешировать домашний объект. Соответственно:

в entity-бине сделать свойство типа фабрики и инициализировать его в setEntityContext

Но, в целом, могу порекомендовать другой подход. Этот же подход рекомендуют bea и ibm )))
Следует все-таки пользоваться CMP-relations, а проблема доступа к ним из удаленного клиента решается следующим образом: создается метод в удаленном интерфейсе (доступен удаленным клиентам), который локально работает с cmr-полями, а удаленному клиенту отдает Value Objects, т.е. обычные pojo, залитые свойствами связанного объекта.

Вообщем-то этот вариант действительно считается предпочтительным. Думаю, что он может ускорить. Покопайтесь - может и правда получится ускорится

как я понимаю setEntityContext вызывается каждый раз при создании бина?
Если так, то я не понимаю - ну создам я свойство в бине, а как его инициализировать, ведь если
setEntityContext вызывается каждый раз при создании бина то и инициализация (получение ссылок) будет 
вызываться каждый раз? или нет? поясните плз.



Т.Е. создаётся Session Bean, который локально работает с Entity Beans, а возвращает "всё что угодно" (String, Collection и т.п.) кроме самого компонента (ссылки на него)?

Вам нужно инфы? Их есть у меня )))

У entity-бина сложный жизненный цикл. Изначально создается пул bean instances. В пуле бины - это просто пустые болваночки, несвязанные пока с конкретным значением pk. На этих болваночках отрабатывают finder- и home-методы. При создании этой болваночки вызывается setEntCtx у неё.
Затем, когда клиенту понадобятся конкретные данные, он вызывает create или find у фабрики. Фабрика выбирает произвольную болваночку из пула, ассоциирует с ней занчение pk и, возможно, заливает в неё данные из базы. Теперь этот bean instance уже не в пуле, а в кеше (состояние ready).
Перемещение объекта из пула в кеш и обратно может происходить когда угодно, это называется пассивизация/активизация.

Это сообщение отредактировал(а) ekr - 18.7.2007, 17:30

Присоединённый файл ( Кол-во скачиваний: 9 )
 entity_bean_lf.png 16,42 Kb

Да. Обычно "всё что угодно" - это pojo:



Это сообщение отредактировал(а) ekr - 18.7.2007, 17:29

Эх жаль  - видимо EJB всё-таки оправдан для очень сильно распределённых приложений

Добавлено через 4 минуты и 18 секунд
У меня в БД есть 10000 записей (в таблице), они отображаются в Entity Beans, так вот поиск через findAll() работает настолько 
медленно (0,5-2 мин), что видимо придётся глядеть в сторону простого RMI.
 (Просто через RMI та же работа выполняется за 8 с., а прямая выборка из БД за1-2 с.)

а чего жаль-то? ))))

да нет, и локально они себя отлично чувствуют ))))

Добавлено @ 20:08

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

да, entity-бины не демонстрируют рекорды скорости, не для этого они. 


к слову, если совсем уж все тормозит, то надо посмотреть в сторону оптимизации. может, неправильно установлены размеры пула и кеша, так что при загрузке большого количества бинов из базы просто своп сплошной получается (((

Это сообщение отредактировал(а) ekr - 18.7.2007, 20:17

мне бы хотелось всё-таки оперировать не чем угодно, а объектами - а это накладненько :(

да, накладно.
лучше логику работы со связанными (cmr) сущностями переместить в локальный для них session-бин (шаблон session facade).

Покалупаюсь исчо, попробую как-нибуть оптимизировать работу 

Спасибо за дискуссию.

оптимизируйте, они золотые (С)золотой теленок
)))

А для чего они?