.NET remoting and singletons

[ASB]

Ok, so I'm just going mad but this seems a little odd.

I create a remotable object in the server with a well known type of singleton.

I can ther create it with 'new' or with Activator.GetObject.

However, if I create it with 'new' when the client request the object with Activator it gets a new one. When it is created in the server with GetObject the client gets this one.

Doesn't seem quite right to me.

[minestrone]

pass by value and pass by reference issue?

I dunno, if I was asked in an interview that is what I would say.

[scotspine]

what constructors have you implemented?

[ASB]

pass by value and pass by reference issue?

I dunno, if I was asked in an interview that is what I would say.

Nah, tis simply the way it behaves. It just 'feels' a bit wrong, though to be fair I don't really see what else they could have done since there isn't any sort of intrinsic singleton type in .NET.

[jmo21]

using Single call instead of singleton (in the config, not your code)?

shouldn't you be using WCF now anyway

[ASB]

using Single call instead of singleton (in the config, not your code)?

shouldn't you be using WCF now anyway

WCF - on W2K (yes it does have to run on kit that old)

Single Call won't help since the object is created then discarded, BUT that does give me a way forward since I could (I think) write a proxy which just delegates, however it still leaves the problem of the client having to get a remotable proxy and this seems to be the issue. GetObject will only create a proxy if there is a server side object also created with GetObject.

TBH it's a god awful implementation since the object in question is the message passing system but I really do need the yucky global singleton across multiple processes because a lot of the data is inherently non serializable.

Good job it doesn't have to scale though......

[ASB]

what constructors have you implemented?

There is only a private sub new, but that is accessible to the remoting infrastructure. OF course that does have an advantage in that it means GetObject is the only way to create it, thus clients can't go around creating them will nilly.

[DSW]

I've not done any .net remoting, so talking a little bit out my backside, thats allowed around here isnt it? I dont really think is particularly a remoting problem.

if you think about creating a singleton manually, you need to create a static method getInstance or whatever, which will either create or retrieve a the singleton and basically keep a hold of a reference to instance and thread sync it.

object o = new object() is never going to be able to give you a singleton because you just told it to create a new one (by definition of new). Calling activator.getObject is basically the getInstance implementation and will either create an object or get a reference to one + plus it got a bit of remoting 'magic'

Am I making sense or nonsense?

[Shimano105]

Yep, singleton pattern requires private constructor with static getInstance method - otherwise it ain't a sinlgeton

[Weltchy]

ASB, I must admit that all through today, having kept an eye on this thread, I've been wondering exactly what the issue was that you were having.

I'm guessing there wasn't one and that you were having a gripe about .NET remoting in general???