ASP.net Storing Session in Database

ASP.net Storing Session in Database

Old forum URL: forums.lhotka.net/forums/t/4559.aspx


vdhant posted on Wednesday, March 26, 2008

Just wondering if anyone has had any experience with CSLA, ASP.net and storing the session in the database rather than inproc.

The reason why i ask is that at first i thought that it was going to be simple but when i thought about it the default implementation for enabling this feature within ASP.net is that the web server will contact the database server directly. This goes against the model that CSLA puts forward. Hence i was wondering if anyone has dealt with this problem with CSLA and ASP.net before.

Thanks
Anthony

dlambert replied on Wednesday, March 26, 2008

ASP.Net session implementation should be independent of CSLA, shouldn't it? In fact, as long as everything you're storing in session is serializable, you should be able to switch implementation from inproc to session-server (in-memory or in-DB) just by changing your configuration. It's really not connected to how CSLA persists business objects, if that's what you mean.

JoeFallon1 replied on Wednesday, March 26, 2008

I agree with dlambert.

The key point to consider is that the CSLA database (and server) are NOT necessarily the same server and database as the ASP.Net session DB. In fact the DBs have to be different but the servers could be the same. It is your choice.

But if you are remoting to the CSLA DB then the APS.Net DB server should be a different box.

Note: for an app of any size you really should skip the InProc session state as it is too volatile and gets lost on AppDomain re-starts.

I use StateServer in a web farm.

Note: Serialization of session can be a perf killer if you store large objects in it. I probably have way too much stuff in my session state but I try hard to keep large BOs out of it once they are no longer needed. e.g. Result page lists are kept in session while paging or sorting - but once a slection is made the list is removed from session and the next page is rendered based on some key value extracted from the selected record.

Joe

 

vdhant replied on Thursday, March 27, 2008

Hi guys
Thanks for the reply.

Firstly, Joe i have not had any experience with using a StateServer but i would imagine that the objects still need to be Serializable, is that correct? Also is there any perf difference between using a state server and using the default in-DB config session management?

Also my question about the database and CSLA is as follows. If you are splitting the client and the server in a web situation, chance are you are doing it because of security reasons. In this case the only server that can contact the database server is the server box and not the client box that runs the business objects and asp.net. Hence if i use the default implementation of storing the session in-DB via the config the client server will be trying to access the database server directly when it does not have access to do that, only the server box (as in the server that run the application data access code). Hence how does one handle this case??? Thus why I brought in CSLA and the fact that one might need to use a command object to retrieve the session and pass it onto the session handler or something.

Thanks
Anthony

tmg4340 replied on Thursday, March 27, 2008

I think you may be getting a little confused... Smile [:)]

The "default" database-based session storage is a state server - StateServer is not the proper name of a product.  Basically, if you switch to database-based session storage, you are introducing a database server into the process, and thus taking a performance hit.  All your session objects need to be serializable.

As for your other question - if you're going to use the built-in ASP.NET facilities for database-based session storage, you have to give your IIS server access to a database to store session state.  As Joe said, it doesn't have to be the same database as your application data, but it can be.  If you dedicate a database server for session state, then you can lower your risk exposure, and you'll help keep performance up in a web-farm environment - all your web servers won't be contending with other apps for database resources.  If you can't/won't do that, then you'll probably have to develop a custom session handler (not a trivial exercise), and you'll take another performance hit as you introduce another server into the process.

HTH

- Scott

JoeFallon1 replied on Thursday, March 27, 2008

Anthony,

Yes - all objects in session must be serializable if you use State Server or SQL Server.

You are still mixing up the idea of the database for session being the same as the DB for CSLA. They are different.

For example,

1. Client browser is on a PC.

2. Client contacts Web Server.

3. Web server has a local SQL Server running for ASP.Net session information storage. (see the connection information below:)

<sessionState mode="StateServer" stateNetworkTimeout="15" cookieless="AutoDetect" timeout="40" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"/>

4. The Web Server contacts a different SQL Server remotely for CSLA and processes data to send to the client.

Joe

Copyright (c) Marimer LLC