In my Azure web role code I have a CustomIdentity class derived from System.Security.Principal.IIdentity. At some point .NET runtime tries to serialize that class and serialization wouldn’t work. Trying to resolve that I searched a lot and found this answer and tried to inherit my class from MarshalByRefObject.
Now once my CustomIdentity class inherits from MarshalByRefObject there’re no serialization attempts anymore and my code works. However I’d like to know the performance implications of using MarshalByRefObject class.
My code runs like this. First the request comes to IIS and is passed to the authentication code that creates an instance of CustomIdentity and attaches that instance to HTTP context. Then some time later the same HTTP context is passed to the ASP.NET handler that accesses that CustomIdentity instance at most once. The CustomIdentity object lives for the duration of request and is then destroyed.
Now with serialization my CustomIdentity would be serialized into a stream, then deserialized from that stream into a new object. With MarshalByRefObject there’s no serialization but a proxy is created and the access will be marshaled via RPC to where the actual object resides.
How expensive will using MarshalByRefObject be in this scenario? Which – MarshalByRefObject or serialization – will be more costly?
MarshalByRefObjectmeans that all calls (methods, properties, etc) are proxied over the wire. This potentially means that instead of transferring the data once and then running multiple methods etc locally on the transferred data, you are making a network call every access. How many times (per request) is a role tested, for example? or the name queried? I honestly don’t know, but I’m guessing it is more than 1 (all totalled). Plus the original setup costs…The bandwidth probably won’t be significant, but latency is very significant, especially if you have distributed nodes (since you mention a cloud scenario).
Personally, I would avoid
MarshalByRefObjectlike the plague, but up to you…