Are Activator/Remoting Proxies Thread-Safe?

[Jules Winfield Guest]

I have a singleton object that's accessed via remoting by way of
Activator.GetObject():

SomeObject
someObj=(SomeObject)Activator.GetObject(typeof(SomeObject),someUrl);

My question is: Is the proxy returned by Activator.GetObject() thread-safe?
I know that my IMPLEMENTATION of SomeObject has been built in a thread-safe
way -- but is the PROXY generated by GetObject() thread-safe?

In other words, if I create the 'someObj' proxy at startup, can I safely
make method calls against it from multiple threads?

Thanks,

Jules

[Steven Cheng [MSFT] Guest]

Hi Jules,

As for .NET remoting object, the proxy object you get at client-side is
actually using a Transparent Proxy and RealProxy class object to
communicate with the backend server object. As the same to most other
standard .net framework classes, only static/shared properties are marked
as "thread-safe", other property/methods are not guaranted to be
thread-safe. Therefore, you may need to add your own code logic to ensure
complete thread-safety.

#RealProxy Class
http://msdn2.microsoft.com/en-us/lib...ng.proxies.rea
lproxy.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxx.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

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

>NNTP-Posting-Date: Fri, 04 Apr 2008 12:18:40 -0500
>From: "Jules Winfield" <Jules.Winfield@xxxxxx>
>Newsgroups:

microsoft.public.dotnet.framework.remoting,microsoft.public.dotnet.general

>Subject: Are Activator/Remoting Proxies Thread-Safe?
>Date: Fri, 4 Apr 2008 10:18:40 -0700
>
>I have a singleton object that's accessed via remoting by way of
>Activator.GetObject():
>
>SomeObject
>someObj=(SomeObject)Activator.GetObject(typeof(SomeObject),someUrl);
>
>My question is: Is the proxy returned by Activator.GetObject()

thread-safe?

>I know that my IMPLEMENTATION of SomeObject has been built in a

thread-safe

>way -- but is the PROXY generated by GetObject() thread-safe?
>
>In other words, if I create the 'someObj' proxy at startup, can I safely
>make method calls against it from multiple threads?
>
>Thanks,
>
>Jules
>
>
>

[Jeroen Mostert Guest]

Steven Cheng [MSFT] wrote:

> As for .NET remoting object, the proxy object you get at client-side is
> actually using a Transparent Proxy and RealProxy class object to
> communicate with the backend server object. As the same to most other
> standard .net framework classes, only static/shared properties are marked
> as "thread-safe", other property/methods are not guaranted to be
> thread-safe. Therefore, you may need to add your own code logic to ensure
> complete thread-safety.
>

That doesn't make sense. How is a proxy "transparent" if you need to add
additional logic for thread safety? Existing clients certainly aren't going
to be doing that. Keep in mind that we're talking about a proxied object
that's thread safe itself.

> #RealProxy Class
> http://msdn2.microsoft.com/en-us/lib...ng.proxies.rea
> lproxy.aspx
>

That means nothing. The "not guaranteed to be thread safe bla bla bla" is
boilerplate; it just means the MSDN isn't giving guarantees. It may very
well be that some of the methods of RealProxy aren't thread safe, but the
client of the transparent proxy won't be using those explicitly.

I'd be surprised if the designers got this one wrong.

--
J.