Как хранить ссылки на объекты на протяжении жизни всего клиента?

[fedotxxl]

Всем привет =)
Предположим у меня есть вид / база, к которому пользователь часто обращается, пока работает в среде. Зачем мне постоянно получать данные объекты (Set db = ns..., Set nv = db...). Что если один раз получить и дальше хранить в памяти? Как можно сохранить объект, пока пользователь работает в LN? Может CAPI, могёт ещё какие-нить нестандартные конструкции?

 

[Omh]

На итертрасте было про это дело

Ссылка скрыта от гостей

пару лет назад:
Там было и про объекты, и про очереди и всё такое...

 

[fedotxxl]

Omh
Спасиба, вот очень интересная ссылка по теме -

Ссылка скрыта от гостей

 

[Omh]

Да, читал когда-то.
Я по идее именно эту тему и искал, но сразу не нашёл.

Скажу сразу, что сам не пробовал

 

[fedotxxl]

Потестировал я

Ссылка скрыта от гостей

Получилось:
Нужно что-то, что будет постоянно поддерживать жизнь объекта "DCN_Obj.ObjCollection"
Метод Add не может принимать самописные классы. Я так понимаю их где-то нужно регистрировать...

Есть идеи по развитию?

 

[lmike]

если касается не UI (и не привяз. к LS) - можно обойтись без подобных "извращений"...
любой класс из jvm библиотек (например lib/ext) будет жить (ежели его там и создать) всё время жизни Нотусов. неНотусёвые классы - точно, Нотусёвые не проверял, но отличий быть не должно
безо всяких КОМов и винды

типа вызывем ф-цию из библиотеки - кот. создает объект и возвращает ссылку

 

[fedotxxl]

lmike
Пример можно?

 

[lmike]

готового для выкладывания - нет
концептуально - я привел схему
пишем jar , в кот. некая ф-ция

class ExamplePerssistent{
static Session gses=null;
public static Session getSession(){
if(gses==null){
//Create new session
......
}
return gses;
}
}

т.о. не создавая инстанса класса (ExamplePersistent): ExamplePersistent.getSession() выдаст некую "глобальную" сессию
т.к. этот jar "проинициализирован" на всё время жизни Нотусов, то и все его объекты будут обладать подобной жизнью

 

[ToxaRat]

давно подобным увлекаюсь действуя по принцыпу давать пользователю уже "обработанные данные", а если он обращается повторно то поднимаю ему их из "кеша"

 

[fedotxxl]

Уточню задачу
Как напрямую передать объект из одного клиента в другой
Вот эта вещь -

Ссылка скрыта от гостей

- почти позволяет это сделать. Только две проблемы - COM сервер должен быть постоянно кем-то поднят и на самописные классы функция ругается

 

[lmike]

это уточнение не даёт ясности...
чем создание "перманентного" Нотус объекта в java библиотеке не устроит?
ведь ссылку на него можно получить во время жизни jvm Ноусов, а оно равно жизни инстанса Нотуса

 

[vincent_vega]

если касается не UI (и не привяз. к LS) - можно обойтись без подобных "извращений"...
любой класс из jvm библиотек (например lib/ext) будет жить (ежели его там и создать) всё время жизни Нотусов. неНотусёвые классы - точно, Нотусёвые не проверял, но отличий быть не должно
безо всяких КОМов и винды

типа вызывем ф-цию из библиотеки - кот. создает объект и возвращает ссылку

Отличная идея! Спасибо за интерсную идею!

 

[fedotxxl]

lmike
Такой вопрос - можно ли таким образом сохранять в памяти любой объект, заранее неизвестный (т.е. коллекцию, в которую можно добавить/взять любой объект
И главное - что делать с LS?

 

[lmike]

давайте вопрос поделим так:
-формирование объекта происходит на основе кода (не так ли?), этот код содержится в библиотеках (как пр-ло)
т.о. создавать объект можно написав любой класс в библиотеке, а сделать его переманентным - вынос за пределы видимости базы (т.е. - внешний jar).
Объект не может быть неизвестным - ибо его пишет программист Мы конечно можем дойти до RMI или CORBA и добавить (для динамики) рефлекшн, но стоит оно того?

-какими объектами должен манипулировать LS? Если имеем стринги, их массивы, скалярные переменные - LS2J подойдет. Организовывать колекции можно и на java классах (и даже проще будет)...

Да - объекты LS передавать не получится, но если на LS не зацикливаться - то оно и не надо.
Понятно, что сущ. LS код, под такую модель либо переделывать, либо модель не использовать

одно из серьёзных ограничений - UI, но это (как мне кажется) и КОМ модель не потянет

 

[lmike]

забыл ещё одну деталь (неприятную)...
сцуконотус жвм убивает Thread (даже глобальные), в агентах точно (апосля выхода из агента)

 

[lmike]

вспомнил еще одну особливость ...
swing объекты нотуса не уничтожают
др. словами - создавая свинговое окошко (класс от JFrame) мы получим его перманентным
кто хочет удостоверится - пущает jdbcsearch экзампел от Сергея (он выкладывал на Интертрасте)

а вот в восьмерке - свинг (по-крайней мере под линух 64-бит) не пущается (жалуется на секурити топмост окна AWT)
это тоже оборимо, но метод убийственный (мне известен) - в секуритях жвм установить пермишн на всё (потому как неизвестно на какой конкретно класс и как надо)