TRemoteDataModule и DCOM

← →
Michail Dalakov (2004-01-02 12:35) [0]

Как "чисто" ликвидировать COM-объект со стороны сервера?

← →
sniknik (2004-01-02 12:40) [1]

отключи от него всех клиентов, сам "упадет" (в смысле завершится, и выгрузится)

← →
Michail Dalakov (2004-01-02 13:05) [2]

Это понятно, это происходит автоматически, если отпускается ссылка на интерфейс. Но вопрос в другом. Клиент по техническим причинам не всегда может отпустить ссылку на интерфейс, если он ему уже не нужен. В результате счетчик ссылок на сервере не обнуляется и COM-объект продолжает жить. На сервере постепенно накапливается количество умерших объектов, в пустую расходуя память. Освобождение памяти уничтожая ненужные TRemoteDataModule
на сервере не является "чистым", т.к. ComClassManager об этом ничего не узнает, в результате на сервере остается ненужный поток
и другой мусор.

← →
Delirium (2004-01-02 13:18) [3]

Как реализован сервер - Single Instance или Multiple Instance ?

← →
Michail Dalakov (2004-01-02 13:29) [4]

Фабрика класса главного RDM:
TComponentFactory.Create(ComServer, TMainRDM,
Class_MainRDM, ciMultiInstance, tmApartment);

Фабрика класса дочерних RDM:
FChRDMFactory:=TComponentFactory.Create(ComServer,
TCh,Class_Ch, ciInternal, tmApartment);

Доступ к функциям дочерних RDM извне осуществляется через интерфейс главного RDM

← →
Delirium (2004-01-02 13:38) [5]

А сервер - dll или приложение ?

← →
Delirium (2004-01-02 13:42) [6]

На самом деле это без разницы, только за dll-сложнее следить.
А раз Multiple Instance, то в конструктор объекта или в событие OnCreate надо добавить код - таймер, который бы обнулялся при вызове методов обекта и если объектом никто не пользуется, например, пол-часа - вызывай деструктор. Не гарантирую что всё пройдёт гладко, возможно будут патери памяти и Exception-ы, но всё-же лучше чем ничего ;)

← →
Michail Dalakov (2004-01-02 13:44) [7]

Сервер в виде EXE-приложения.

← →
Delirium (2004-01-02 13:47) [8]

Лично я всегда делаю Single Instance и Exe-шник, можнет быть это не экономно по отношению к памяти, за-то объекты можно "гасить" прямо из Task Manager-а

← →
Michail Dalakov (2004-01-02 13:55) [9]

To [6]
Лучше чем ничего уже реализавал, но как говорилось в [2] есть потери памяти, как сделать лучше чем есть? Взглянув, на модули
VCL(ComServ, ComObj), заметил что все не так просто.
На написать свой ComClassManager или что-то подобное нет не только времени, но и смысла

← →
Delirium (2004-01-02 14:04) [10]

Если у тебя создаются не 1000-чи объектов можешь попробовать пойти по пути [8] - слава богу, что винда освобождает память из под приложения даже если оно завершается аварийно 8)

← →
Michail Dalakov (2004-01-02 14:05) [11]

To [8]
> можно "гасить" прямо из Task Manager-а

Не понял вручную, что-ли?

Какой в этом смысл?

← →
Delirium (2004-01-02 14:09) [12]

Не вручную конечно, это я для примера сказал, всё так-же таймером. Только гасится всё приложение.

← →
Delirium (2004-01-02 14:14) [13]

А можешь написать собственный менеджер и следить за процесскаи "снаружи" - всё ведь работает на одной машине. И даже если с COM-ом что-нибудь произойдёт - грохнешь процесс извне ;)

← →
Michail Dalakov (2004-01-02 14:38) [14]

Гасить всё приложение, я могу даже используя процедуру ForEachFactory ComClassManager-а. Но это мне кажется не совсем хорошо, даже не потому-что один клиент создает в среднем десяток COM-объектов на сервере, ну например, нельзя будет посмотреть в приложении сервера список активных User-ов, терминалов с которых подключаются User-ы, ресурсы сервера и др. информацию. Хотя все это можно писать в какой-то log потом просмаиривать.
Все же я считаю, что сервер должен быть реализован в виде одной единственной инстанции или в виде службы.

TRemoteDataModule и DCOM Найти похожие ветки