search

rohita / MemcachedSessionProvider

A highly available, high performance ASP.NET session state store provider using Memcached.
Apache License 2.0
25 stars 7 forks source link

Running on a multi-process / server system #1

Open dazbradbury opened 10 years ago

dazbradbury commented 10 years ago

Hi Rohita,

Firstly - excellent work. A non-blocking Session provider, everyone should be using this as default!

However, I'm running into some issues when running on Appharbor. All is fine locally, so I'm guessing it has something to do with running across multiple processes on multiple machines and keeping in sync?

Do you generate a key somewhere for the cache that is machine specific?

FYI - I migrated from: https://github.com/friism/Memcached-Providers

Thanks again, Daz.

dazbradbury commented 10 years ago

I noticed you were using the following to generate your keys:

HttpRuntime.AppDomainAppId

Took a stab at that being different on different appharbor deployments, and thus, changed it to:

System.Web.Hosting.HostingEnvironment.ApplicationVirtualPath

Seemed to do the trick! All currently working smoothly. :-)

rohita commented 10 years ago

Hi Daz,

Sorry for the late response. You are right about AppDomainAppId. It returns the application path of the web site in IIS. E.g. \LM\W3SVC\1. Here 1 is the instance ID of the web site. To maintain session state across different web servers, the application path of the web site must be the same for all servers.

The problem you were seeing happens if on one web server the instance ID of the app is, say, 1 (\LM\W3SVC\1). On another web server the instance ID may be 2 (\LM\W3SVC\2), making the application paths between web servers different.

This behavior is also true for the default Microsoft ASP.NET session state provider.

Your solution works if there is only one application in IIS using the Memcached servers. But if you share the cache servers among many different sites, then you could run into overlaping session keys. Therefore we do need a way to get the application name in the key name.

I have seen some other Session State providers use a setting "ApplicationID" in web.config instead of IIS application path. That allows for sharing of same cache servers among many applications while also giving the developer control over the naming of the AppIDs. I will make sure that I get this in a future update.

Thanks, Rohit

dazbradbury commented 10 years ago

Thanks Rohit - Yep, I guess setting the value manually in the web.config makes sense.

This currently works for me, but I'll look at changing to a web.config based solution if it's more foolproof.