Pergunta

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?

Foi útil?

Solução

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.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top