3

After having some difficult hours mulling over some architecture issues for my server-based application, I feel I am going to have to use singletons to accomplish my goal. Purely for the following reasons (justifying my smell):

  • I don't need to pass expensive objects deep into a call stack
  • I can perform functions on singleton management objects within any context. (A lot of the code already exists and therefore I am unwilling to rewrite extensive chunks of otherwise working code)

Apart from that, Singletons suggest another problem. My server-based application is essentially a DLL with a class that can invoke multiple instances of servers. The server instance class contains the singleton management objects. Ordinarily, this would be managed by a Windows Service, so server:machine ratio will be 1:1.

So you could view it as (where -> is 1:1, => is 1:many):

MACHINE -> ServiceHost (Windows service?) -> Server instance -> Singleton management objects

However, we would like to allow for an SaaS model, which would require a service host (be it a Windows Service or Win32 application) to be able to fire up multiple servers as required by the business. Therefore, a physical machine could run a single server host, which would run multiple server instances.

Which would be (where -> is 1:1, => is 1:many):

MACHINE -> ServiceHost (Windows service?) => Server instance -> Singleton management objects

The problem is that these singletons would be shared across servers. Which cannot happen. The singletons must be 1:1 with the server instance.

Assuming I cannot move away from these singletons, is it possible for me to separate these server instances from each other by invoking the service instance class as a separate process/memory space?

I can only imagine that I would need to fire up multiple EXEs (anduse WCF to manage), one for each server instance. This would obviously not be very good.

Program.X
  • 7,250
  • 12
  • 49
  • 83
  • Thinking about it, could I use Reflection somehow? – Program.X Jan 08 '10 at 11:38
  • How is the server instance going to access the management objects? – Lazarus Jan 08 '10 at 11:41
  • What are you doing? Your problem doesn't seem to be described in the above; and I have no concept of what "Scaling Singletons" means ... (How do you have more than 1 ...; that seems counter-intuitive, to say the least :P) – Noon Silk Jan 08 '10 at 11:43
  • @Lazarus: The server instance (say IServerInstance) has properties that it initialised on Start(). They're just static properties specific to that service instance. – Program.X Jan 08 '10 at 11:47
  • 1
    @silky: I'm basically trying to take an application that was a Web app to be a Win32 service, but adding the possibility of scaling up instances of servers to offer a potential SaaS business case. So if you have IServerInstance with its own static properties, I need to be able to fire up a second instance, independent of the first - but preferably without an intermediate layer - eg. separate process and therefore WCF – Program.X Jan 08 '10 at 11:48
  • 1
    Program.X: Ah-ha. I see. Seems like you want to launch it in a new AppDomain, like Benjamin suggests below. But I don't think you mean "Win32" service (i.e. not even .net). I'd say it's worthwhile considering if you can just completely remove the singleton, but that may not be practical. Good luck! – Noon Silk Jan 08 '10 at 11:52

1 Answers1

2

What about different AppDomains for different "Instances"?

Benjamin Podszun
  • 9,679
  • 3
  • 34
  • 45
  • Looking into this, this looks very promising. It looks as if I can even communicate between the host and the AppDomains (containing single server instances). Thanks. – Program.X Jan 08 '10 at 11:56