I notice in the azure examples they are using:
<sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">
Can someone explain what this is used for with MVC3? I'm very confused about session state. Do I really need to use it if my application does not have anything like a shopping cart? Is it needed if I just want to do simple authentication? I removed the code from my web.config and my authentication still seems to work.
If you're publishing your application to Azure and you're using Session in any way (this includes MVC's TempData) then you will probably need to use some kind of central storage for session, rather than using the default "InProc" provider which just stores the user's session in the application's own memory. With azure, you can use, among others, SQL Azure or the AppFabric Cache (still in CTP).
Here is a good lab for AppFabric:
http://msdn.microsoft.com/en-us/gg457897
And here's one for SQL Azure (not supported): http://blogs.msdn.com/b/sqlazure/archive/2010/08/04/10046103.aspx
This is because you could have mutiple instances running or you instance could be moved at any given moment.
It sounds like your application doesn't currently use Session State so you won't need to worry about it. (although, remember that the TempData dictionary uses Session under the hood)
Related
I have a MVC3, ASP.NET 4.5 web application deployed on Azure Websites, using SQL Azure.
Currently I am using some "inproc" Session variables which I need to remove since I am going to start using multi website instances. I could just store the Session variable values in the SQL Azure DB, but I am also using TempData, which also uses Session state, "under the bonnet". Due to TempData use, I do need to implement an "out of proc" session solution.
I have seen some recommendation for using AppFabric caching, but I am unsure whether this is still current, and whether it is correct for Azure websites.
Also my development setup is on a Windows 7 machine with SQL Server 2008 R2. So a solution should be transferable with minimum pain.
There is also a "thread agility" issue with session variables, and a open source solution has been created using REDIS caching, but I have no experience of this, or REDIS. See: GitHub site
So thoughts I have are:
1) Angieslist/AL-redis custom provider, see: GITHUB link . Not entirely sure that this can be used in a Azure Websites application.
2) Appfabric. Not sure if this is relevant or current for Azure Websites.
3) SQL Azure session provider.
4) Azure Table storage.
5) Use a custome TempData provider to persist via cookies ie https://www.nuget.org/packages/BrockAllen.CookieTempData.dll/1.2.2, and then remove other session variables.
I would be very grateful for advice on a good Azure Websites session implementation mechanism which is simple. My data is pretty simple. I think I have one object which I quess I will need to serialize, probably via Json.NET
If you have more than one instance of an Azure Web Site, sticky sessions are enabled by default by the load balancer. This means that a user will be directed to the same instance (server) and that you'll be able to use session state in your app.
You may also find the Distributed Caching section (Ch 12) of this ebook helpful http://aka.ms/CloudApps_PDF
I'm currently designing a new website built on MVC and I wonder what is the right way to manage state.
The state should contain the userId and some structs of the user info, and should be kept during the whole session of the user while he's logged in (across http requests)
The important criteria:
1) Support scalability
2) Performance
The easy way is to use the Session object, but it doesn't support scalability. If different requests during the session go through different IIS servers, the session won't be kept. Although I've heard of load balancing tools which route all requests of a single session through the same machine, I'm not sure that it's a good practice to rely on it (isn't it?)
Another option that I've read about, is keeping the state data in special state servers which are running a RAM DB (like Cassandra for Linux or Redis for Windows). But it seems to me an overkill at this stage of the development.
Do you have any other suggestions?
I would like to start with something simple at the moment, but keep the design ready for a more advanced solution at the future.
Any best practice or code/design suggestions will be appreciated.
Thanks,
Edi.
(1) Use Sql Server to Store Session State
(2) Use Memcached as a Session State Provider
(3) Cook up your own solution using Caching on an external caching provider: look into using something like the ServiceStack Caching Framework. Using this, you can use Redis, Memcached, Azure or AWS to handle caching.
Next, create a KeyFactory to handle generation of keys for specific items. The item keys would include the UserId (which you would always have from FormsAuthentication UserId (assuming that you are using FormsAuthentication). Then store any Session data for the user in the cache. Using this approach you are using Caching in place of Session, and the cache can be shared across multiple servers.
Note: you can have different approaches regarding clearing out the user's data whenever they begin a new session. Potential approaches include:
Include the user's session start dateTime in the cacheKey, and auto-expire entries when they are no longer fresh
Clear out all potential entries for a user when they begin a new session
If you are using .NET 4.5 and dependent on the type and amount of information you are keeping on users you may want to look at using claims to store information about the user. In .NET 4.5 all Principals inherit from ClaimsPrincipal. ClaimsPrincipal already uses claims to store the user name, roles and other information. You can create your own service to transform claims, which will allow you to add additional information to the Principal user.
I have a few classes that are instantiated using ninject "Session Scoping" - because these objects get passed between controller methods and then only get persisted once, this technique worked well for this project.
With Azure's multi-hosting capabilities I assume that InSessionScope is no longer reliable because any of the servers could be servicing my request.
Does anyone know if I am wrong and can still use Session Scoping with Azure or does anyone know of an alternative to this?
In this case you would use a custom session state provider that works with Windows Azure:
Session State Provider for Windows Azure Caching
Azure Providers
Now if you use a session state provider other than InProc, you'll need to make sure that whatever you store in session is serializable. You should test this since this might have an impact on how your application works today.
I would like to be able to share some data between an asp.net mvc application and a python/django application . The type of data I would like to share are authentification or session data.
This is of course possible as long as you access some shared resources between both frameworks. There are likely several ways of doing it but one of the most obvious would be using some shared backing store ie. database or maybe even memcached which would be faster. I'm not a Django user but as far as I know memcached is supported in it...
There is of course a more complex scenario related to this and that is data compatibility. You will likely have to use some interchangable format that both frameworks understand ie. XML, JSON, BSON or similar. So even when using memcached you will have to do this translation.
How I would share session...
Make the Session Cookie sub-domain agnostic
<httpCookies domain=".mydomain.tld" />
Have my two sub-domains that I want to share session between
www.mydomain.tld [ASP.net MVC app]
extra.mydomain.tld [Python app]
Create a simple web service or generic handler in ASP.net that returns the user's session serialized in JSON or XML.
If you use generic handler remember to use the IReadOnlySessionState or IRequiresSessionState interfaces on the class.
Now from extra.mydomain.tld you can call your www.mydomain.tld/[Get/Set]SessionValue handler or service. It will pick up on your ".mydomain.tld" cookie and allow sharing modifying values.
I would recommend the following approach using a shared database (could be a shared cache or any other datastore):
When a user accesses one of your applications at your domain, you create a cookie with the key "_shared_session" and with the value of a random string generated by your application;
Save the value of this cookie into the database and relate it to a JSON object holding the data you want to share between applications;
When the user accesses the other application, you verify if the cookie with the key "_shared_session" exists and read its value;
With the value of the cookie, you can retrieve the shared JSON object.
Quick answer: there should be a filter that look for a shared cookie before creating a new session
There is an option for storing Session state in MS SQL Server database which is available out of the box. Use the steps from the next kb http://support.microsoft.com/kb/317604
It's more about configuration, not implementation.
You can write your own custom storage provider but is there any reason for that?
I'm not familiar with python, but there are at least ODBC drivers for it
http://wiki.python.org/moin/SQL%20Server
Greetings,
Windows Azure only supports SQL Azure Session State for multiple instances.
I'm thinking what whether storing the objects in session will boost any performance for given scenario below:
Scenario:
I've got MVC Application where it's header and footer are populated from DB. I've created ApplicationController which inherits from controller. This applicationcontroller in turn will be inherited by actual controllers such as Home/Account etc.
I'm thinking of loading all these footer/header value in to session and use the session object for any subsequent requests.
Does anyone know whether this will boost any performance? Only reason I'm asking is that SQL Azure Session would do the same thing i.e. query SQL Azure Session storage for each request?
Thanks.
I would say that right now the amount of performance improvement you get from one option over the other is pretty negligible. The only way to know for sure would be to create some test scenarios.
Having said that, App Fabric Caching is coming out of CTP in less than a month and includes a session provider. If you were willing to use it you'd have two options:
Use the App Fabric Caching session provider and the session technique you've described above and it should be faster than either of the SQL options
Use the cache directly to provide the header and footer information (you'll still need to keep the data in SQL, but you can populate the cache on demand when headers and footers are requested)