[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

singleton problem - remote / local calls don't yield the same result

Stephan Steiner

6/10/2004 3:18:00 PM

Hi

I'm hosting a singleton remote object in my app. I'm using Static
Initialization as described on MSDN. Here's a code snippet to give you an
idea of what I'm doing:

public sealed class Singleton: IRemoteInterfaceDefinition
{
private static readonly Singleton instance = new Singleton();
private string message;

private Singleton(){}

public static Singleton Instance
{
get
{
return instance;
}
}
public string Message
{
set
{
message = value;
}
}
//IRemoteInterfaceDefinition members
public string getMessage()
{
return message;
}
}

now, if I set the message from the program hosting this class as follows:

Singleton.Instance.Message = "some message"

then make a call

string message = IRemoteInterfaceDefinition.getMessage();

from the remote side, message is null. But since the object is a singleton
(and is registered as such), shouldn't my remote call return the value of
message I have set locally on the app hosting the object? How do I have to
change my program to permit this? I noted that problem when working with
remote events.. I have a service app that fires remote events, and a GUI app
to catch them (in case somebody is logged in).. when I trigger the events
from my GUI controller app, they are properly fired and returned to the GUI
app, but when I trigger them from within the service (or from within a
regular executable that I build to rule out the service as a cause for my
problems), my service/exe informs me that there are no event listeners
configured, even though the GUI app has registered those.. thus I came to
the conclusion that my singleton object is not really a singleton but that
there are in fact multiple instances of the object floating around on my
machine.

Any ideas are welcome

Regards
Stephan


2 Answers

Sunny

6/10/2004 5:29:00 PM

0

Hi Stephan,

you do not need to implement the singleton pattern to get what you want.

Change your code as follows:


public sealed class Singleton: MarshalByReferenceObject,
IRemoteInterfaceDefinition
> {
> private string message;

//default constructor will be provided by the compiler
>
> public string Message
> {
> set
> {
> message = value;
> }
> }
> //IRemoteInterfaceDefinition members
> public string getMessage()
> {
> return message;
> }
> }
>

Then instaniate and expose your object to remoting as follows:


//register here the channel, but not the object
Singleton myremobj = new Singleton();
RemotingServices.Marshal(myremobg, "<myuri>", typeof
(IRemoteInterfaceDefinition));


Now at the server you have access to the object thru myremoobj, so you
can set the Message property.

And the clients will access that same instance.

You have to consider that every remoting call is made on a different
thread, so your class have to implement some thread safety.

Also, you have to manage its lifetime as well. Otherwise even you still
have a reference to the object in your server and it is not garbage
collected, when its lifetime expires, it will be disconnected from the
remoting infrastructure and will not be accessible from the client.

Hope that helps

Sunny

Stephan Steiner

6/11/2004 8:20:00 AM

0

Exactly what I needed. Thanks a bunch.

Stephan
>
> you do not need to implement the singleton pattern to get what you want.
>
> Change your code as follows:
>
>
> public sealed class Singleton: MarshalByReferenceObject,
> IRemoteInterfaceDefinition
> > {
> > private string message;
>
> //default constructor will be provided by the compiler
> >
> > public string Message
> > {
> > set
> > {
> > message = value;
> > }
> > }
> > //IRemoteInterfaceDefinition members
> > public string getMessage()
> > {
> > return message;
> > }
> > }
> >
>
> Then instaniate and expose your object to remoting as follows:
>
>
> //register here the channel, but not the object
> Singleton myremobj = new Singleton();
> RemotingServices.Marshal(myremobg, "<myuri>", typeof
> (IRemoteInterfaceDefinition));
>
>
> Now at the server you have access to the object thru myremoobj, so you
> can set the Message property.
>
> And the clients will access that same instance.
>
> You have to consider that every remoting call is made on a different
> thread, so your class have to implement some thread safety.
>
> Also, you have to manage its lifetime as well. Otherwise even you still
> have a reference to the object in your server and it is not garbage
> collected, when its lifetime expires, it will be disconnected from the
> remoting infrastructure and will not be accessible from the client.
>
> Hope that helps
>
> Sunny