In my middleware course, I asked the question of how to realize a statefulSingleCall remoting server. I expected to hear something about external state storage, e.g. in a database. To my surprise, most students proposed to use a static variable in the server implementation for keeping the state between calls.

This idea results from a pure programming-language thinking, and (for most students) from successful experimentation. Looking under the hood, it is not completely obvious that this will work in all cases. Static variables are managed by the CLR as entities bounded to a loaded class, in this case the server class. According to most sources, static variables are only garbage collected when the class is garbage collected. This can only happen if the surrounding application domain is unloaded. For a standard remoting server, this is very unlikely to happen ever.

Things become more interesting with a different runtime host than the operating system. If you use IIS, it could decide to unload your whole server application if it is not triggered often enough, or if memory is whole.

All in all, relying on static variables in a virtual runtime environment is bad style.

• http://www.navwin.com/Topics/AppDomainRecycling/AppDomainRecycling.aspx
• http://stackoverflow.com/questions/851370/garbage-collection-of-static-members

BTW: I know that .NET Remoting is deprecated in favour of WCF, but it is still a very helpful teaching tool.