Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TRemoteDataModule и DCOM [D7]

Michail Dalakov © (2004-01-02 12:35:00)

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

Michail Dalakov (2004-01-02 14:38:00) [1]

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

Delirium (2004-01-02 14:14:00) [2]

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

Delirium (2004-01-02 14:09:00) [3]

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

Michail Dalakov (2004-01-02 14:05:00) [4]

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

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

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

Delirium (2004-01-02 14:04:00) [5]

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

Michail Dalakov (2004-01-02 13:55:00) [6]

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

Delirium (2004-01-02 13:47:00) [7]

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

Michail Dalakov (2004-01-02 13:44:00) [8]

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

Delirium (2004-01-02 13:42:00) [9]

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

Delirium (2004-01-02 13:38:00) [10]

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

Michail Dalakov (2004-01-02 13:29:00) [11]

Фабрика класса главного 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:18:00) [12]

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

Michail Dalakov (2004-01-02 13:05:00) [13]

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

sniknik (2004-01-02 12:40:00) [14]

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »