In my .NET application i kinda need a session provider which is persistent like Sql Server Session Provider but also provides good performance like InProc Session Provider.
So the idea that i come up with is , to keep session data in memory cache of the application but also use a background thread to store/update it at sql server database. In case, IIS application recycles or somehow the data in memory cache is lost, we will fetch session data from database into memory cache again.
I need to implement a custom session provider which works the way i explained above.However i dont know, if it is good idea or a bad one. I have searched online but there are not many custom session providers.
Any suggestions?
As a future reference, i think what you were asking is basically use the Session State with Sql Server In-Memory. Have a look to the following guide: ASP.NET Session State Provider for SQL Server In-Memory OLTP.
Cheers
Related
Everything I know about Asp.Net Session Providers I know from this MSDN page. However, at work we're using the MySql Session Provider and I'm confused about one detail: Session Expiration.
On that MSDN page, it says:
The ASPState database includes a SQL Server Agent job that
periodically (by default, every 60 seconds) calls the stored procedure
DeleteExpiredSessions to remove expired sessions.
I have a few problems with this. We're using MySql so there is no SQL Server Agent to do this. Also, there doesn't appear to be any Routines at all for our instance of the database. For the record, we do have autogenerateschema="true" so if it used Routines, I'd imagine it would have made them.
Can somebody shed some light on the MySql specifics of the Session State Store and Session Expiration?
From the source code, it looks like the MySqlSessionStateStore class takes care of it by running a timer that clears expired sessions.
Greetings,
What do I have to consider when you are coding an ASP .Net website in regards to if the application will run in a environment where there is a load balancer for the IIS?
All user sessions are running by them self with no shared data between sessions. Single connections to MSSQL. Images and files for download will be hosted on one single server.
Windows Server 2008's, C# and .Net 4.0.
The most obvious item is session state. If you are load balancing, multiple requests from the same user may move between servers. The default session provider for ASP.NET (in-proc) doesn't support this (the user would get a new session each time they moved). The easiest solutions are to move to a ASP.NET state server or SQL Server sessions.
FYI: Both of these solutions require that everything that you put into Session be [Serializable]. The in-proc provider doesn't have this requirement, so you may see some runtime errors and need to modify your code when you change providers.
You're going to need to move your session state into the session state service. Avoid keeping objects in session...if you must keep an object in session, make sure it's marked with the Serializable attribute (this is how it is stored, by serialization).
In general, avoid using Sessions. Keep in mind that ASP.Net Session != FormAuthentication. Chances are that your database will be a bottleneck long before the web server, depending on the nature of the application.
Ok I'm sure this is pretty obvious. But when you say session state is persisted on the "server" in memory, are we talking about IIS or what? When I think of Server-side session State, I think memory in terms of IIS app pools and such. Am I off base or missing anything here?
http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
the term "server" could mean many things. Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)
I wish MS would have explained what they mean because that's pretty relative.
Specifically this, "store on server"
Storing Data on the Server (in memory)
• Session state
• Application state
• Profile Properties
so "on the server" where in memory and what process/app is handling each of these?
" Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)"
Each site runs in an application pool and each application pool is basically a process on your web server. If your session is configured to be in process, your session objects will be stored in that process' memory
It depends. By default it's in the worker process memory, but it can be on a dedicated state server or in SQL or your own custom provider.
From MSDN:
ASP.NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
ASP.NET is just a framework; it's a collection of classes, and they execute code. It's this code that provides you with session state, and it stores the information about your session state in some objects, just like a dictionary or similar.
(When doing In Proc, then you have state server, sql server, and custom, where custom can be anything as long as someone has written some code implementing the right interfaces)
I'm working with an asp.net application that stores most data in a database and not session. I'm wondering of the pros and cons of each and which is the better way to go. For example, you have a pretty busy site and instead of storing user specific variables in session, there is a DB table called user data and it can store all user specific data that can be accessed from any page by querying the database. Which is the better way to go, session or database?
Session (but it depends a lot of the session configuration) :
No database access, or less.
Temporary storage : you may lose the information, at least when the session ends.
Maybe some security issue, depending on where you store the session information
Not shared : you may have issues if you're using a server farm, one server may not have access to the other server session.
May not work if the client disabled the cookies.
Database :
Database traffic for each postback if you need the information on each page.
Permanent storage.
No information stored with the client (cookies...).
Shared : data accessible from any server on a web farm.
Please note that you can store Session information in database. That's why I use the word "may" in the Session part.
See here some session configuration and possibilities
Anything stored in session state will vanish when the AppDomain is reset.
You could avoid that by using an out-of-proc session state handler, but that's no better than a database.
Interesting question. If it's data that's not important across sessions (say, last page viewed) -> session. If it's data that should be persistent (say, password) -> database. The interesting case and the one you probably refer to: Data that should be persistent but is also used often (say, the username). From these, I tend to copy those values from the DB into the session that allow me to work without database access in pages with trivial tasks.
In many cases, I use Session to store temporary data about the... well... "session". In ASP.NET, session is configurable. You can use in-proc (default) which uses the server's memory. You can also configure session to use a database or a session management tool (in case server memory is a problem or you move to a cluster/farm environment).
Session is meant to be temporary. This is great when you are truly storing data about the user who is using your application at that moment. When the user leaves the app and his/her session expires, the memory is freed up. You don't have to manually clear anything out.
Session uses the server's memory. As long as you have enough memory and you're not on a server cluster, this works great. Memory is fast, so getting and setting data in session is very fast and uses zero network bandwidth.
Have said all that, in a few of my apps, I have session configured to use SQL. It's basically the same as using the database directly, but I don't have to deal with DAL... just let the framework work for you.
I have my default website in IIS7 bound to an ASP.NET application. This application is using the ASP.NET State Server to store session data. I would like to add an additional ASP.NET MVC application to this website. Is it possible to share the session between these two applications using the state server? I've read that there are ways to do it storing session data in SQL Server, but I can't find any documentation on doing it with the state server.
Thanks,
Nathan
Best advice I have to to switch to SQL Server for the session state store. It's not difficult to set up if you already have SQL Available and use the following technique:
Sharing sessions across applications using the ASP.NET Session State Service
For this situation you are probably best to write your own custom session state provider that runs on a SQL database.
details are here:
http://msdn.microsoft.com/en-us/library/aa479034.aspx
the reason i'd write a custom provider is because simply settings up an SQL session provider will not be enough as the applications will use different session keys and therefore will not share state between them. by writing your own session provider you can have fine grained control over the whole process and therefore override the checks in place using the default sql session provider.