1

I have an out of process com server, specifying CLSCTX_LOCAL_SERVER as the context, and REGCLS_MULTIPLEUSE for the connection type. This results in a single server process being reused by multiple calls from multiple clients.

I’m now wanting to make some changes to the server, which unfortunately can not work with a single process shared amongst clients (there are reasons for this, but they're long winded). I know you can set the server to use REGCLS_SINGLEUSE as the connection type, and this will create a new process for the OOP server each call. This solves my issue, but is a non-starter in terms of process usage; multiple calls over short periods result in many processes and this particular server might be hit incredibly often.

Does anyone happen to know of a mechanism to mix those two connection types? Essentially what I want is a single server process per calling process. (ie, client one creates a process, and that process is reused for subsequent calls from that client. Client two tries to call the server, and a new process is created). I suspect I could achieve it by forcing a REGCLS_SINGLEUSE server to stay open permanently in the client, but this is neither elegant nor possible (since I can’t change one of the clients).

Thoughts?

UPDATE As expected, it seems there is no way to do this. If time and resource permitted I would most likely convert this to an In-Proc solution. For now though, I'm having to go with the new behaviour being used for any calling client. Fortunately, the impact of this change is incredibly small, and acceptable by the clients. I'll look into more drastic and appropriate changes later.

NOTE I've marked Hans' reply as the answer, as it does in fact give a solution to the problem which maintains the OOP solution. I merely don't have capacity to implement it.

cal

cal
  • 33
  • 6
  • So you want all the benefits of an in-proc solution without it being in-proc. Is that about right? Because what your describing, one per process (the "proc" in that vernacular) is precisely what that does, with only process isolation being the missing ingredient. – WhozCraig Jan 23 '14 at 16:04
  • So far (it's legacy code) I've found nothing to suggest it does need to be out of process, and personally I would have made it in-proc. Unfortunately, the scale of this change doesn't justify the testing that would be required when changing something like that. For now, I'm plastering the new behaviour onto the OOP and accepting that it alters the old client behaviour slightly. – cal Jan 28 '14 at 11:26
  • @cal, the best solution is the Application coclass mentioned by Hans. – Ben Jan 28 '14 at 11:40

1 Answers1

5

COM does not support this activation scenario. It is supposed to be covered by an in-process server, do make sure that isn't the way you want to do it given its rather major advantages.

Using REGCLS_SINGLEUSE is the alternative, but this requires you extending your object model to avoid the storm of server instances you now create. The Application coclass is the boilerplate approach. Provide it with factory methods that gives you instances to your existing interfaces.

I'll mention a drastically different approach, one I used when I wanted to solve the same problem as well but required an out-of-process server to take advantage of bridging a bitness gap. You are not stuck with COM launching the server process for you, a client can start it as well. Provided of course that it knows enough about the server's installation location. Now a client of course has complete control over the server instance. The server called CoRegisterClassObject() with an altered CLSID, I xored part of the guid with the process ID. The client did the same so it always connected with the correct server. Extra code was required in the client to ensure it waits long enough to give the server a chance to register its object factories. Worked well.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • REGCLS_SINGLEUSE is basically a non-starter, the code itself handles the multiple processes fine, but the client might hit that object many times a second, creating a resource hog which just isn't acceptable. The more drastic approach would work, but my access to the clients is somewhat slim, two of them are already in release. There are many things askew with the design of this object, unfortunately testing resource isn't available for more drastic changes. – cal Jan 28 '14 at 11:27
  • 1
    +1. the creativity on the single coclass-server per client is brilliantly simplistic, sir. The words "that's awesome!" ensued. Certainly not normal, yet wonderfully elegant. Thanks for that! – WhozCraig Jan 28 '14 at 15:24