1

I have read about storing session state out-of-process but still in memory by configuring the web app to use a provider such as StateServer

I have a List<int> that contains accountIDs that I would like to be shared among all servers in a webfarm. The list is not session data relating to any particular account, it is a global list that I would like in memory (but probably out-of-process) so that it can be checked by each server in the farm for each request to see if it contains an accountID.

Can this data be shared in the same way that session state is shared? Please can you give details of how this should be done?

Is this a good solution? Will there be a performance hit of many servers trying to access the same list?

EDIT: extra into...

In my app user accounts have an _accountStatus which if set to suspended is used by the app to restrict what the user can do. The _accountStatus is persisted in a bespoke authentication ticket. The problem is users can stay signed in, they could sign in today, go away and comeback in a month and still be signed in. Meanwhile a site admin may have suspended their account, but because the _accountStatus is persisted in the authentication ticket it is now incorrect and the user still has access that they shouldn't.

So when a user's _accountStatus is changed by an admin, their _accountID is added to the list. Then on every request the list is checked. If the account is on the list then it must reload it's _accountStatus from the database (which always has the correct value) and update the authentication ticket.

So yes maybe persisting the list in SQL Server is the best solution.

Another solution might be to store the _accountStatus not in the authentication ticket but in the session. When a new session is started it could be loaded. But now there is the problem of what if an admin decided to suspend an account during a user's session. How can the applicaion access the session for that user and update the _accountStatus from outside of the HttpApplication? Or inbetween the user's requests, if you see what I mean?

Duncan Gravill
  • 4,552
  • 7
  • 34
  • 51

1 Answers1

2

There is nothing built-in for this.

Concurrent write access to such a list would require locking for data consistency. Are writes common? I hope not because that would destroy performance.

I recommend you keep that list in SQL Server. Maybe a text file on a file share is enough, too.

usr
  • 168,620
  • 35
  • 240
  • 369
  • Thanks usr, writes would not be common but the list would have to be checked on every request. I suspect constantly doing sql lookups would not be great for performance. I think I will have to find an alternative solution. – Duncan Gravill Mar 31 '12 at 21:34
  • 1
    I guess you are already talking to SQL Server for every request multiple times. Simple queries are incredibly cheap (like 0.5ms). You could also cache the result for 10s or so. – usr Mar 31 '12 at 21:35
  • 1
    In that case maybe it is viable, and possibly the best solution. – Duncan Gravill Mar 31 '12 at 21:51
  • Ok, clearly this data should be stored in SQL Server and cached for a few minutes (which means account suspension can be delayed for a few minutes, which shouldn't be a problem?). Even caching for just 10s would take away almost all load. One DB query per 10s is *nothing*. – usr Mar 31 '12 at 22:25
  • Thank you for your expertise and help usr. I would still be interested to know if data in a session can be modified from outside of a HttpApplication that has loaded that session. But I guess that is another question. Thanks, – Duncan Gravill Mar 31 '12 at 22:36
  • I don't think so @FunkyFresh84 but if you are worried about the cache being outdated, then you can reset it on writing to that list. Makes sense? Then you'd have your data up to date and still make use of cache!+ – Fabio Milheiro Apr 02 '12 at 13:22