3

I have one instance of web application connected to multiple databases. Based on the domain name (for example www.shop1.com, www.shop2.com, ..) I switch the connection string in the Entity Framework.

shop1.com -> Database1

shop2.com -> Database2

shop3.com -> Database3

So far so good.

I am also using Sql Server session state and I want to switch the session state database just like I am switching database for my data.

shop1.com -> SessionStateDatabase1

shop2.com -> SessionStateDatabase2

shop3.com -> SessionStateDatabase3

Thanks in advance for your help.


More information if you want to know why I am doing this:

Actually I am implementing multi-tenancy. The description above shows three sites. In fact, I have more than 50. And the number of sites is going to grow in the next few months. At the moment all the sites are deployed separately which means whenever I have to roll out a patch or an update I deploy all 50 sites. Maintaining sites this way is becoming a nightmare. So I was thinking about putting 5 to 10 sites on one instance, depending on their usage, so that I have fewer instances to maintain.

Oxon
  • 4,901
  • 8
  • 40
  • 54

3 Answers3

1

In cases like this, I always look at the source code of the framework. First I find out where the configuration stores the session state connection string, then I find where it is being used. The private class System.Web.SessionState.SqlSessionState.SqlSessionStateStore has a method OneTimeInit(), where it reads the connection string. Here I noticed that there is support for partiniong, see here: http://msdn.microsoft.com/en-us/library/aa478952.aspx . I've never heard of this before, but it looks like it does exactly what you want, you can store session state in multiple databases, based on any kind of criteria you want. +1 for the question by the way, this is a cool feature. Also, if it doesn't work out, you could try implementing your own SessionStateStoreProviderBase implementation, which is publicly overridable.

fejesjoco
  • 11,763
  • 3
  • 35
  • 65
  • Thanks @fejesjoco. I am definitely going to look into it next week as it seems pretty promising. – Oxon Nov 22 '13 at 14:02
  • 1
    I doubt there's any other nice way to do it, and this a supported and nice way. Implementing the IPartitionResolver is not the easiest task, because you need to map session ID's to connection strings. So if you want to decide based on the domain name, then you need to map domain names to session ID's somehow. Either you store that mapping somewhere (in the Global Session_Start event), or... The easiest trick I can think of is using a custom ISessionIDManager and putting the database identifier directly into the session ID. So when you look at the session ID, you know which database it's in. – fejesjoco Nov 22 '13 at 17:04
0

Since the session state connection is not managed by your code, it won't be possible for you to switch it. Its a application level configuration and the beyond code control. But the need for this should not arise. A single server will be able to manage the session state for all three domains you have. The only concern maybe when a user moves from shop1.com to shop2.com and still retains the old session.

user2956314
  • 174
  • 4
  • The reason that a user can move from shop1.com to shop2.com raises concerns. Moreover, I am also very concerned about the security of the data if a user manages to do something on shop2 while he is logged in on shop1 only. – Oxon Nov 15 '13 at 15:01
  • I am sure there must be a workaround or a different way of handling the situation. – Oxon Nov 15 '13 at 15:03
  • 1
    If the session ID is stored in a cookie, the browser will not send it for different domains. So there is no problem there. – user2970362 Nov 20 '13 at 19:22
0

Is there some reason that you would not consider running ( I am assuming, the same code ) as three separate web applications?

  • one error does not take down all three sites
  • session state is separated by application
  • allows for scale ability sites can be allocated to different systems as growth dictates
Mike Beeler
  • 4,081
  • 2
  • 29
  • 44
  • Good question. Actually I am implementing multitenancy. In fact I do not have three sites. I have more than 50. And the number of sites is going to grow in the next few months. At the moment all the sites are deployed separately which means whenever I have to roll out a patch or an update I deploy all 50 sites. Maintaining sites this way is becoming a nightmare. So I was thinking about putting 5 to 10 sites on one instance, depending on their usage, so that I have fewer instances to maintain. – Oxon Nov 21 '13 at 09:30
  • A multi-tenant model has more to do with the database and less to do with the hosting containers for web sites, if you think that the problem is hard with a couple at 50 you are probably looking at a web farm all the more reason to move to multiple sites one database. – Mike Beeler Nov 22 '13 at 01:04