views:

368

answers:

2

Hi,

I would like to know how threads are handled on the server side using MarshalByRef objects.

Given my remoted MarshalByRef class:

public class MyRemotedClass : MarshalByRef
{
  public int MyInt;
  public string MyString;
}

Client code (single threaded):

MyRemotedClass m = GetSomehowMyRemotedClass(); 
m.MyInt = 5; // Write operation 1
m.MyString = "Hello World"; // Write operation 2

On the server side, we have the two write operations. I assume that the thread is from the ThreadPool. However, since the class is MarshalByRef, both opeations are separate remote procedure calls. Are they going to run on separate thread? If yes, can it occur that operation 2 is going to be executed before operation 1 finishes?

PS: Making MyRemotedClass MarshalByRef is BAD decision. But I am not allowed to change that, so please do not propose that.

+2  A: 

I'm not an expert on this, but I'd really expect the write to MyInt to have reliably completed before the client event tries to write to MyString unless you've got some funky asynchronous behaviour going on.

After all, if the assignment fails for some reason the only sensible way of handling that is to throw an exception before proceeding, IMO.

Jon Skeet
+2  A: 

Indeed, as far as I would think about it, setting the 2 properties is not happening asynchronously, so the client is waiting until the 1st RPC is finished before it will start with RPC 2.

Anyway, if your MyRemotedClass is not configured as a singleton server-activated object, also keep in mind that for every RPC that you do on MyRemotedClass, a new instance will be created on the server. That means that the remote object should not contain any state.

Frederik Gheysels
I don't *think* it will create a new instance if it's MarshalByRefObject. The whole point of MBRO (as I understand it) is that only a reference is marshalled, and the object itself "lives" on the server.
Jon Skeet
seconded - hence remoting lifetime services / leases.
Marc Gravell