Reply to: .NET remoting and singletons

[DSW]

Come back COM RPC all is forgiven (maybe).

no, no, I'm not forgiving it! COM was a bit mixed, the coolest project I remember working on with it was written in VB and had a separate front end server, middle tier (COM+) and finally a db server. You generated the proxies from COM+ manager on the middle tier and got an MSI which you ran on anywhere. very cool. However I also remember the deployment instructions, I think they were at least 10 pages long

As for the transparent code, this is one of the reasons why spring is so cool. Working on my plan b and I have modular components frontend, business stuff, dal etc and by changing the profile I build the frontend with I can change how it talks to the business tier. The idea is I can then put a thick client on a well as a web one.

[ASB]

sounds like using activator just seems to work and new is a bit of a mess, I guess that what you (M$) get for butchering the new keyword... I think I prefer spring remoting as it doesn't even involve any code just a few lines of config! more of java thing though

Yep. I think that's my conclusion really. Though of course one of the ideas behind remoting is that it is supposed to be invisible to a consumer. It isn't. I can make it so by producing my own proxys but at this rate there will be too many levels of indirection and IPC over a named pipe before any code get executed anywhere. Come back COM RPC all is forgiven (maybe).

[DSW]

sounds like using activator just seems to work and new is a bit of a mess, I guess that what you (M$) get for butchering the new keyword... I think I prefer spring remoting as it doesn't even involve any code just a few lines of config! more of java thing though

[ASB]

What happens if you use new in the server, does that also create a new object?

Well, after tonights experiments the answer seems to be "it depends". It seems that:-

a) If the server (yes I did write server) has not registered a client channel it will always create a new object. This will be a real object.

b) If the server has registered a client channel (yes I did write server then client) then it will create a new object if it does not exist, otherwise it will return a proxy. If the object did not exist when the new one was creatred the reference returned it still a proxy.

c) If a client registers the type then if new is called after the type is registered it will get either:

- a new object if the server has not yet created one (this is a proxy to a new object)

- a proxy to a pre-existing server object

d) If a client gets the object through activator it will always get a proxy. [Though if it then tries to access it if the server has not created an instance it will get a disconnected type exception].

e) The message sinks get completly screwed.

So, I think it's time to give up and serialise and create a throwaway private proxy.

Edit: On ipc channel. Willl try sometime soon with TCP and HTTP. Maybe it's something to do with NamedPipes but shouldn't be since it's the same damn interface. (ho ho)

[ASB]

Surely using "new" must mean a new object and would be incompatible with the singleton'ness on the other end? What happens if you use new in the server, does that also create a new object?

It would be a hideous bodge to make new do something other than create a new object. As somebody else said, the singleton pattern means you don't (and can't) use new because the contructor is private and you can only get access via a static GetInstance function.

But I've never used remoting (or VB) either.

Oh yes. There's definitely a hideous bodge. I wouldn't mind if there were consistancy across the server and clients - but there isn't. If the type is registered as a singleton on the provider then:-

- If a client calls new and it has not called registerwellknownclienttype then it gets a new object.

- If a client calls new and it has called registerwellknownclienttype then it gets a proxy to the singleton (or a proxy to a new object if it is single call rather than singleton).

So 'n' different clients calling 'new' get the same object (but only if it is registered as a well known client object). Of course marking the constructor as private gets round most of this. THe only way the server can create the object will be via remoting, but that will give a proxy, along with the IPC overhead. Pah.

[DSW]

Surely using "new" must mean a new object and would be incompatible with the singleton'ness on the other end? What happens if you use new in the server, does that also create a new object?

It would be a hideous bodge to make new do something other than create a new object. As somebody else said, the singleton pattern means you don't (and can't) use new because the contructor is private and you can only get access via a static GetInstance function.

But I've never used remoting (or VB) either.

welcome to M$ , I really do dislike some of their design decisions, but hey I like checked exceptions and they think nothing is better... But i do like a lot of the C#/.net stuff as well (not to make it sound like I hate them, as I don't)

I believe the idea is that new will actually create a proxy to that bean, that it is a singleton is hidden by the remoting stuff/proxy. It appears that new then just knows what to do with a bit of remoting magic or something. This is basically why I would probably used getObject as its not abusing new

ASB - no worries I know what it is like when you start trying things and none of them work, you can spend a day on it, then go back to what you though you did originally and it works, can be annoying as hell!

[VectraMan]

the bit that stands out is: To activate a well-known object with new, you must first register the well-known object type on the client using the RegisterWellKnownClientType method

Surely using "new" must mean a new object and would be incompatible with the singleton'ness on the other end? What happens if you use new in the server, does that also create a new object?

It would be a hideous bodge to make new do something other than create a new object. As somebody else said, the singleton pattern means you don't (and can't) use new because the contructor is private and you can only get access via a static GetInstance function.

But I've never used remoting (or VB) either.

[ASB]

interesting, certainly clears things up when I can see some code. I did a little digging:

http://msdn.microsoft.com/en-us/library/0315hz94.aspx

http://msdn.microsoft.com/en-us/library/3xzb9z8s.aspx

the bit that stands out is: To activate a well-known object with new, you must first register the well-known object type on the client using the RegisterWellKnownClientType method

did you do this on the client side? tbh just using getObject makes more sense to me rather than magic new behaviour.

if that doesn't do it I might (emphasis on might, which also means probably wont) try it in c# to see if its a language screw up (you would have thought they would have spotted something like that though...)

I **think so**, but I had so many different combinations of registered channels both client and server trying to fiugre out what's going wrong with the sinks that it is entirely possible that I that point I observed this on the server I didn't have RegisterWellKnownClientType. I'm still having so many problems with sinks I think I might give dyno rod a call.

[Weltchy]

try it in c# to see if its a language screw up (you would have thought they would have spotted something like that though...)

I wouldn't make that assumption. C# and VB were written by different teams with MS (I think) and its a case of the one hand not talking to the other!

[DSW]

interesting, certainly clears things up when I can see some code. I did a little digging:

http://msdn.microsoft.com/en-us/library/0315hz94.aspx

http://msdn.microsoft.com/en-us/library/3xzb9z8s.aspx

the bit that stands out is: To activate a well-known object with new, you must first register the well-known object type on the client using the RegisterWellKnownClientType method

did you do this on the client side? tbh just using getObject makes more sense to me rather than magic new behaviour.

if that doesn't do it I might (emphasis on might, which also means probably wont) try it in c# to see if its a language screw up (you would have thought they would have spotted something like that though...)

[ASB]

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

I think it's compulsory.

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?

Bit of both. In a remoted scenario the instancing rules are such that for server activated object if they are registered as a singleton then that object is returned to all callers - however it is goes out of scope on the server it can get recycled, thus it's not really a singleton unless the server keeps a reference to it. So I would expect to get the one unique object - because that is what the documentation say will happen.

The issue is that if the server creates one this is not served up to remote clients UNLESS it is explicity created with Getobject.

[There was a claim by MS somewhere that instantiation by NEW or GetObject was synonymous for remoted objects - but it isn't].

[ASB]

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???

Bit of both really.

In the server:-

'Use as singleton
RemotingConfiguration.RegisterWellKnownServiceType ( _
GetType(RemotingLib.Wibble), "wibble", _
WellKnownObjectMode.Singleton)

then

dim a as new Wibble

This does not give a proxy. It gives a new instance of the real object. I **thought** that once a type was registered then ALL instantiation was supposed to be done by the remoting infrastructure, patently not the case.

As a result of the above then in the client if you do:-

Activator.GetObject(GetType(Wibble),"ipc//blah blah" then this will create a new object (since the one created at the server end was a real object) and then return a transparent proxy to it.

Granted changing the server code to use Activator instead of creating one and everything is fine.

-----------------------------------------

Real winge at the moment is binary channel sinks.

Server creates serializable object (there is an IPCServer channel). Can't remot to the bloody thing because there is no client sink. Try as I might I can't find the right combination of channel registration. Bah, humbug.

Anyway, ultimately I need to seperate the code to that which is called from remoting and that which is executed on the server in order to reduce number of round trips.

[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???

[Shimano105]

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

[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?