Вне процесса COM-сервер — один серверный процесс на каждый вызывающий процесс?
У меня есть внепроцессный com-сервер, в качестве контекста которого указана CLSCTX_LOCAL_SERVER, а для типа подключения REGCLS_MULTIPLEUSE. Это приводит к повторному использованию одного серверного процесса несколькими вызовами от нескольких клиентов.
Теперь я хочу внести некоторые изменения в сервер, который, к сожалению, не может работать с одним процессом, совместно используемым клиентами (есть причины для этого, но они затянуты). Я знаю, что вы можете настроить сервер на использование REGCLS_SINGLEUSE в качестве типа соединения, и это будет создавать новый процесс для сервера ООП при каждом вызове. Это решает мою проблему, но не является началом процесса использования; множественные вызовы за короткие промежутки времени приводят к множеству процессов, и этот конкретный сервер может поражаться невероятно часто.
Кто-нибудь знает механизм смешивания этих двух типов соединений? По сути, мне нужен отдельный серверный процесс для каждого вызывающего процесса. (т. е. клиент один создает процесс, и этот процесс повторно используется для последующих вызовов этого клиента. Клиент два пытается вызвать сервер, и создается новый процесс). Я подозреваю, что мог бы добиться этого, заставив сервер REGCLS_SINGLEUSE постоянно оставаться открытым в клиенте, но это ни изящно, ни невозможно (так как я не могу изменить одного из клиентов).
Мысли?
ОБНОВИТЬ
Как и ожидалось, кажется, нет способа сделать это. Если время и ресурсы позволят, я, скорее всего, преобразую это в решение In-Proc. На данный момент, я должен идти с новым поведением, используемым для любого вызывающего клиента. К счастью, влияние этого изменения невероятно мало и приемлемо для клиентов. Я рассмотрю более радикальные и соответствующие изменения позже.
НОТА
Я пометил ответ Ганса как ответ, поскольку он действительно дает решение проблемы, которая поддерживает решение ООП. У меня просто нет возможности это реализовать.
кал
Решение
COM не поддерживает этот сценарий активации. Предполагается, что он покрыт внутрипроцессным сервером, поэтому убедитесь, что это не так, как вы хотите, учитывая его довольно значительные преимущества.
Использование REGCLS_SINGLEUSE является альтернативой, но для этого необходимо расширить объектную модель, чтобы избежать бури экземпляров сервера, которые вы сейчас создаете. Application Coclass является стандартным подходом. Предоставьте ему фабричные методы, которые дают вам экземпляры для существующих интерфейсов.
Я упомяну совершенно другой подход, который я использовал, когда хотел решить ту же проблему, но требуется внепроцессный сервер, чтобы воспользоваться преимуществом преодоления разрыва битности. Вы не застряли с COM, запускающим процесс сервера для вас, клиент также может запустить его. При условии, конечно, что он знает достаточно о месте установки сервера. Теперь клиент, конечно, имеет полный контроль над экземпляром сервера. Сервер с именем CoRegisterClassObject () с измененным CLSID, я скопировал часть guid с идентификатором процесса. Клиент сделал то же самое, поэтому он всегда был связан с правильным сервером. Клиенту потребовался дополнительный код, чтобы он ожидал достаточно долго, чтобы дать серверу возможность зарегистрировать свои фабрики объектов. Работал хорошо.
Другие решения
Других решений пока нет …