Может ли быть важно вызывать remove() для сеансового компонента EJB 3 без сохранения состояния? Возможно на weblogic?

Я нахожусь в процессе переноса приложения EJB 2 на EJB 3 (и как приятно удалить все эти дескрипторы развертывания!). Раньше он работал на Weblogic, а теперь работает на Glassfish.

Задача выполняется очень гладко, но одна вещь меня настораживает: текущий код очень тщательно следит за тем, чтобы EJBObject.remove() вызывалась для компонента, когда он выполнил свою работу, а у других разработчиков остались (к сожалению, очень смутные) воспоминания о «плохих вещах». происходит, когда это не было сделано.

Однако в EJB3 класс реализации не реализует EJBObject, поэтому метод remove() не вызывается. И я понимаю, что на самом деле нет никакого смысла вызывать это для сеансовых компонентов без сохранения состояния, поскольку они, ну, не имеют состояния.

Могли ли эти «плохие вещи» быть специфичными для веблогики? Если нет, то что еще? Должен ли я избегать полной легкости EJB3 и оставить удаленный интерфейс, который расширяет EJBObject? Или просто списать это на культовое программирование и удалить все эти предложения try/finally?

Я склоняюсь к последнему, но чувствую себя не очень комфортно с ним.


glassfish weblogic ejb jakarta-ee ejb-3.0
person Michael Borgwardt    schedule 05.05.2010    source источник
comment
Любое обновление? В EJB3 я вижу, что клиенту приходится вызывать метод, аннотированный @Remove. Также вы предполагаете, что у EJB без состояния нет состояния? Они делают. Они не имеют состояния, потому что они не поддерживают диалоговое состояние между двумя вызовами метода (они делают это во время вызова метода).   -  person dalvarezmartinez1    schedule 02.10.2014
comment
@MichaelBorgwardt и др., Поскольку EJB 3 не реализует EJBObject, возвращает ли контейнер прямую ссылку локального компонента на локального клиента? Если это так, есть опасность, что клиент может присвоить значение null тому же самому, и экземпляры пула исчезнут из пулов SLSB. Если клиентские вызовы маршрутизируются через прокси, как в EJB 2.1, что это за тип прокси?   -  person lupchiazoem    schedule 03.08.2018
comment
@mnmopazem: прошло слишком много времени с тех пор, как я работал с EJB, чтобы помнить особенности, но я определенно предположил бы, что локальные компоненты EJB3 передаются клиентам как прямые ссылки, и если вы думаете, что присвоение null ссылке может сделать экземпляры исчезают из пула, у вас есть некоторые неправильные представления о том, как работают ссылки.   -  person Michael Borgwardt    schedule 05.08.2018
comment
@MichaelBorgwardt Интересно узнать о ссылках. Не могли бы вы уточнить то же самое. IOW, если клиент имеет прямую ссылку на bean-компонент, почему назначение null не приведет к его исчезновению из пула. Под «исчезновением» я подразумеваю, что он будет готов к сборке мусора во время выполнения. Я разместил вопрос @ stackoverflow.com/questions/51657404/. Я прошу вас поделиться своими знаниями там.   -  person lupchiazoem    schedule 05.08.2018
comment
@mnmopazem: множественные ссылки на один и тот же объект полностью независимы. Упрощенно, ссылка — это адрес памяти объекта. Установка для одной ссылки значения null никак не влияет на другие ссылки на тот же объект. Объект подходит для GC, если на него нет ссылок. Это очень фундаментальное знание Java, которое вам необходимо понять, а не просто как побочный вопрос в контексте EJB.   -  person Michael Borgwardt    schedule 07.08.2018
comment
@Майкл Боргвардт О. Ну, я понимаю этот момент :) Итак, имея общее понимание и возвращаясь к моему 1-му комментарию - если клиенту назначается прямая ссылка (т.е. объект SLSB), то если клиент назначает null (сразу после получения ссылки), этот объект будет готов для GC. Разве это не так?   -  person lupchiazoem    schedule 07.08.2018
comment
@mnmopazem: только если нет других ссылок на объект. Но если у вас есть объект, назначенный из пула, пул также будет содержать ссылку на объект. В противном случае он будет иметь право на GC после того, как клиент закончит с ним, установка ссылки на null не имеет никакого значения для этого.   -  person Michael Borgwardt    schedule 07.08.2018

Ответы (2)


arrow_upward
1
arrow_downward

Я не знаком с реализацией WebLogic, но не думаю, что это важно. Я ожидаю, что каждый вызов метода в оболочке SLSB будет выделять bean-компонент из пула до вызова метода и освобождать его после, поэтому для удаления() нечего делать.

Я бы списал это на карго-культовое программирование. Предположительно, кто-то однажды забыл вызвать remove для SFSB и обнаружил, что произошли плохие вещи, поэтому шаблон был распространен на все сеансовые компоненты.

person Brett Kail    schedule 05.05.2010
comment
Я не согласен с определением, что звонить EJBObject.remove() не важно. В конце концов, зависит от реализации, является ли EJBObject.remove() неоперативным или нет. В WebSphere, например, это не работает. Проблема в том, что это никогда не было специфицировано. Если сомневаетесь, придерживайтесь спецификации. (Хорошо, что EJB 3 снял большую часть этой ерунды) - person Isaac; 27.11.2012
comment
@Isaac: вы правы, и в разделе 21.4.5.1 спецификации EJB 3.1 это прямо указано в отношении сеансовых компонентов без сохранения состояния: это также зависит от реализации в отношении того, будет ли вызов EJBHome remove(Handle) или EJBObject или EJBLocalObject remove( ) вызывает немедленное удаление экземпляра компонента в зависимости от стратегии реализации контейнера. - person Brett Kail; 28.11.2012

arrow_upward
0
arrow_downward

Верно. Вы не реализуете EJBObject в EJB 3, поэтому вы не можете вызвать метод remove(). Что на самом деле есть в EJB 3, так это внедрение зависимостей, которое работает с EntityManager.

В настоящее время я переношу приложения с EJB 2.1 на EJB 3 и понял, что могу решить эту проблему с помощью EntityManager.

@Resource private EntityManager em;

и в методе удаления вы можете написать em.remove(yourObject);

Надеюсь это поможет

person Hürol Türen    schedule 15.06.2010
comment
Этот ответ не имеет значения. EJBObject не имеет ничего общего с EntityManager. - person Nikola Kolev; 15.08.2013