Sharing session between WCF services

Question

I have been working on splitting up the app tier and web tier of a web application. In the app tier, I managed to separate the business logic into a bunch of services exposed using WCF proxies. The problem is that these services talk to another legacy application that uses a large CLR object as its primary means of communication. To keep things quick, I had been keeping a copy of this object in the session after I created it the first time. Now I know that WCF can do sessions, but the session storage is per service whereas my business logic is now split into multiple services (as it should be).

Now the questions:

1. Is there a way to share session storage between WCF services hosted on the same host?
2. Is this even something I should be doing?
3. If not, then what are the best practices here?

This is probably not the first time somebody’s had a large business object on the server. Unfortunately for me, I really do need to cache this object per user (hence the session).

It’s possible the answer is obvious and I'm just not seeing it. Help please!

Answer 1

I think instance context sharing can help

http://msdn.microsoft.com/en-us/library/aa354514.aspx

Answer 2

As far as I understand WCF, it is designed to be as stateless as it could be. In a session you can remember some values in your service, but objects are not meant to live outside the scope of a session.

Therefore, I'd think you are in trouble.

Of course, there might be some way to store and exchange objects between sessions that I don't know (I use WCF, but I don't know very much about it, apart from what I need for myself).

(if there is a way to share objects between services, it probably would only work on services you host yourself. IIS hosting might recycle your service sometimes)

Answer 3

Perhaps you can wrap this object in a singleton service. This is a service with only one instance, which will not be destroyed between calls. Because you need an object for each user, this service has to manage a list of them and the calling services has to provide the needed authentication data (or sessionid). Don't forget a timeout to get rid of unneeded objects...

Answer 4

Create a facade service which hosts the large CLR object on behalf of the other app tier services. It can work as an adapter, allowing more specific session identifiers to the more advanced app tier services you have created. The facade can provide a session identifier, like a GUID, which your app tier services can use to get re-connected with the large CLR object.

This provides a few advantages:

1. Some of your app tier might not need to know about the CLR object at all. They only communicate with the remote facade.

2. the 'large CLR object' host retains the session object on behalf of the other services who can now share it.

3. The app tiers now have a facade through which they talk to the legacy service. As you work to refactor this legacy service, the app tier doesn't have to change.

Depending on your setup, you may be able to host the facade via in proc hosting which will give retain performance boost you are seeking.

Answer 5

Breaking things up into subservices seems like a good idea if you want to be able to spread the app out over a farm. However, it's important to keep in mind that whenever an object crosses the appdomain boundary at the vary least it will have to be copied in memory.

It all depends on how big the object is and what kind of data it holds.

If you don't want to pass the object because it's too large you may want to make a query API for the service which receives it. In this way you could manipulate that object without having to do expensive serialization or remoting.

Answer 6

Keep it simple. Since you already have access to Session in your WCF, you can use the SessionID from there. Now:

1. Create a static dictionary somewhere, where the Key is your sessionId and the value is the business object you want to store.

2. Instead of accessing the business object in session, just access the sessionid and get the business object from the Value of your dictionary.

(You can also use some type of caching if you wish, for example System.Web.Caching, that way you don't have to cleanup the dictionary manually)