Удаление stateless session-bean из пула

@аriakon · Регистрация: 05.04.2009

Студворк — интернет-сервис помощи студентам

Hi All
Прочитал что удаление stateless session-bean из пула не связано с вызовом remove() home/remote интерфейсов. Цикл жизни таких объектов определяется профилями контейнера.

Вот тогда возникает вопрос, если при удалении я не могу вызвать свой код, то как тогда мне закрыть соединение Connection con.close(),тем самым вернуть con обратно в ConnectionPool? Может jboss это делает сам?

Или же ejbRemove все таки вызывается при удалении, но его вызова я не дождался, а если где можно установить время то я не нашел

@mr_dronski · 01.09.2009, 14:49

поехали

timeout вы выставляете в дескрипторе JCA коннектора. глянете внизу, там есть узлы для количества коннектов, размера пула и его таймаута.

полагаться на ejbRemove не стоит. пример - в бизнес методе вылетает System Exception. бин переходит в состояние doesn't exist, при этом ejbRemove __не вызывается__.

зачем это вы лезете напрямую к ConnectionPool из бина? если вам нужен доступ к базе - юзайте DataSource. по завершению операций с базой __в том же методе__ и в блоке __finally__ делайте conn.close() и все путем

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

если у вас в коде что-то другое - то постите код, там подскажем конкретно

@аriakon · 01.09.2009, 15:42 **[ТС]**

mr_dronski
НЕ НАШЕЛ искал в файле
jboss/server/default/conf/standartjboss
для всех бинов кроме Session Stateless можно установить время жизни.

а сразу закрывать соединения не хочу, т.к. придется его опять забирать из пула когда вновь что то делать понадобиться(в пределах одной и тойже сессии), а вот закрыть его по истечению определенного времени когда сеанс с пользователем будет закрыт и бин удалиться - то что нужно.(т.е. в ejbRemote написать conn.close())

Щас пока могу сделать: это настроить сам pool чтоб соединение закрывалось через опрделенное время, но сеанс то еще не закончен и
пользователь может вновь обратиться к БД, а соединения уже нету.

@аriakon · 01.09.2009, 16:18 **[ТС]**

путанно написал, и не совсем правильно.
Вот что имелл ввиду
Если сделать у STSB con.close() то когда в нем возникнит необходимость у клиента, то он получит бин с закрытым con, т.к. con
создается только в ejbCreate. Вот и получается что надо закрывать con
только когда бин будет точно удален из пула

@Danissimo · 01.09.2009, 16:23

Хе. А почему бы не получать из пула конекшн каждый раз, когда клиент вызывает метод бина? Пул, он на то и пул, чтобы созавать иллюзию закрытия и открытия соединений . Не надо беспокоиться. Надо в каждом методе slsb открывать и закрывать соединение. Реально же соединение будет затребовано из пула, и пул выделит свободное (уже открытое), если есть, или откроет, если нет свободных. Я бы поставил время жизни соединений в пуле в 500 мс.

@аriakon · 01.09.2009, 16:40 **[ТС]**

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

01.09.2009, 17:08

Так ведь пул именно это и делает,делит один коннекшн между несколькими клиентами. причем лучше, чем ты. А если ты в бине будешь держать коннекшн, ты ему помешаешь.

@Danissimo · 01.09.2009, 17:12

Как я понял -- это самоцель. Ну, здесь наука бессильна

) Читай, никак. У slsb и должно быть много клиентов

)

Зачем??? Ты все равно реально не управляешь зарытием и открытием. Даже если напишешь conn.close();, это не будет означать, что содеинение закрылось. Напротив, соединение пометилось как свободное и осталось в пуле до тех пор, пока оно не потребуется или не истечет время жизни свободного ОТРЫТОГО соединения в пуле.

@аriakon · 01.09.2009, 17:34 **[ТС]**

все меня не поняли

под закрытием я имелл ввиду что коннекшен возращается в пул, и соответственно его снова оттуда надо доставать getConnection(), а так
как клиентов много и каждый много раз начинает делать close и getConnection, то получается накладно в сравнении еслиб
был один GetConnection и close()

01.09.2009, 19:40

getConnection() из пула - это быстрая операция. Если уж так чешится чего-то оптимизнуть - 'чешите в другом месте' (с) В настройках того же пула, например, или алгоритме.

Новые блоги и статьи Все статьи Все блоги /
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .
Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .

@аriakon 0 / 0 / 0 Регистрация: 05.04.2009 Сообщений: 78

	Удаление stateless session-bean из пула 01.09.2009, 14:25. Показов 2216. Ответов 9 Метки нет (Все метки) Hi All Прочитал что удаление stateless session-bean из пула не связано с вызовом remove() home/remote интерфейсов. Цикл жизни таких объектов определяется профилями контейнера. Вот тогда возникает вопрос, если при удалении я не могу вызвать свой код, то как тогда мне закрыть соединение Connection con.close(),тем самым вернуть con обратно в ConnectionPool? Может jboss это делает сам? Или же ejbRemove все таки вызывается при удалении, но его вызова я не дождался, а если где можно установить время то я не нашел 0

@mr_dronski 4 / 4 / 1 Регистрация: 13.08.2008 Сообщений: 931
	01.09.2009, 14:49
	поехали timeout вы выставляете в дескрипторе JCA коннектора. глянете внизу, там есть узлы для количества коннектов, размера пула и его таймаута. полагаться на ejbRemove не стоит. пример - в бизнес методе вылетает System Exception. бин переходит в состояние doesn't exist, при этом ejbRemove __не вызывается__. зачем это вы лезете напрямую к ConnectionPool из бина? если вам нужен доступ к базе - юзайте DataSource. по завершению операций с базой __в том же методе__ и в блоке __finally__ делайте conn.close() и все путем соединение будет помечено как свободное, но будет ли оно реально закрыто - вас уже не интересует. если у вас в коде что-то другое - то постите код, там подскажем конкретно 0

@аriakon 0 / 0 / 0 Регистрация: 05.04.2009 Сообщений: 78
	01.09.2009, 15:42 [ТС]
	mr_dronski НЕ НАШЕЛ искал в файле jboss/server/default/conf/standartjboss для всех бинов кроме Session Stateless можно установить время жизни. а сразу закрывать соединения не хочу, т.к. придется его опять забирать из пула когда вновь что то делать понадобиться(в пределах одной и тойже сессии), а вот закрыть его по истечению определенного времени когда сеанс с пользователем будет закрыт и бин удалиться - то что нужно.(т.е. в ejbRemote написать conn.close()) Щас пока могу сделать: это настроить сам pool чтоб соединение закрывалось через опрделенное время, но сеанс то еще не закончен и пользователь может вновь обратиться к БД, а соединения уже нету. 0

@аriakon 0 / 0 / 0 Регистрация: 05.04.2009 Сообщений: 78
	01.09.2009, 16:18 [ТС]
	путанно написал, и не совсем правильно. Вот что имелл ввиду Если сделать у STSB con.close() то когда в нем возникнит необходимость у клиента, то он получит бин с закрытым con, т.к. con создается только в ejbCreate. Вот и получается что надо закрывать con только когда бин будет точно удален из пула 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	01.09.2009, 16:23
	Хе. А почему бы не получать из пула конекшн каждый раз, когда клиент вызывает метод бина? Пул, он на то и пул, чтобы созавать иллюзию закрытия и открытия соединений . Не надо беспокоиться. Надо в каждом методе slsb открывать и закрывать соединение. Реально же соединение будет затребовано из пула, и пул выделит свободное (уже открытое), если есть, или откроет, если нет свободных. Я бы поставил время жизни соединений в пуле в 500 мс. 0

@аriakon 0 / 0 / 0 Регистрация: 05.04.2009 Сообщений: 78
	01.09.2009, 16:40 [ТС]
	можно и так, но я хочу вариант с одним закрытием и открытием. клиентов у бина может быть много. 0

noir
	01.09.2009, 17:08
	Так ведь пул именно это и делает,делит один коннекшн между несколькими клиентами. причем лучше, чем ты. А если ты в бине будешь держать коннекшн, ты ему помешаешь.

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	01.09.2009, 17:12
	Как я понял -- это самоцель. Ну, здесь наука бессильна ) Читай, никак. У slsb и должно быть много клиентов ) Зачем??? Ты все равно реально не управляешь зарытием и открытием. Даже если напишешь conn.close();, это не будет означать, что содеинение закрылось. Напротив, соединение пометилось как свободное и осталось в пуле до тех пор, пока оно не потребуется или не истечет время жизни свободного ОТРЫТОГО соединения в пуле. 0

@аriakon 0 / 0 / 0 Регистрация: 05.04.2009 Сообщений: 78
	01.09.2009, 17:34 [ТС]
	все меня не поняли под закрытием я имелл ввиду что коннекшен возращается в пул, и соответственно его снова оттуда надо доставать getConnection(), а так как клиентов много и каждый много раз начинает делать close и getConnection, то получается накладно в сравнении еслиб был один GetConnection и close() 0

noir
	01.09.2009, 19:40
	getConnection() из пула - это быстрая операция. Если уж так чешится чего-то оптимизнуть - 'чешите в другом месте' (с) В настройках того же пула, например, или алгоритме.