Which Method For Session???

  • Thread starter Thread starter Jim Douglas
  • Start date Start date
J

Jim Douglas

I am starting the analysis and design on how we are going to handle session
data. We are on a large web-farm which limits our solutions. The best
solution is persisting to MS SQLServer but I'm not comfortable with it's
single point of failure or maybe I am missing something there. QueryString
is out for security and HIPAA regulations and most other solutions are
'single-server', cache, etc. I have read the MSDN article titled "Nine
Options for Managing Persistent User State in Your ASP.NET Application",
sure wish there was one more that I could jump on!

I am thinking that we are going to write our own custom sessionManager where
we create the sessionID, write the data to our SybaseDB, pass the sessionID
between page and read back data as required. Now I am thinking about the
format of the data? XML?

Thanks

--
Jim Douglas
http://www.genesis-software.com
http://www.interactiveDesignSolutions.com
Latitude 32.96
Longitude -96.89
 
You can still use the IIS session for creating the session id. That way the
session gets passed via a cookie and the mechanism is already built in.

The solution to the data storage issue depends on how much data you want to
hold. I have implemented custom state classes that I serialize/deserialize
to bytes and store in the db. I have also create multiple objects if I'm
storing a large quantity of data and can split the data so that I only pull
what I need for a specific page request. The nice thing about using custom
objects is the fine grained control you get on the data.

The binary serialization is very easy to implement and the
serialization/deserialization is relatively fast. I would caution against
using a single large blob of data if you are maintaining a lot of session
data.

That's my take.

Jon
 
Jim Douglas said:
I am starting the analysis and design on how we are going to handle session
data. We are on a large web-farm which limits our solutions. The best
solution is persisting to MS SQLServer but I'm not comfortable with it's
single point of failure or maybe I am missing something there. QueryString
is out for security and HIPAA regulations and most other solutions are
'single-server', cache, etc. I have read the MSDN article titled "Nine
Options for Managing Persistent User State in Your ASP.NET Application",
sure wish there was one more that I could jump on!

I am thinking that we are going to write our own custom sessionManager where
we create the sessionID, write the data to our SybaseDB, pass the sessionID
between page and read back data as required. Now I am thinking about the
format of the data? XML?
Click to expand...

How is writing the data to SybaseDB better than persisting it to SQL
Server? If SQL Server being a single point of failure is a problem,
either use a clustered database or manually persist to two different
SQL servers.
 
Jim,

If you have to think about this, think than first what is in your data not
regulary changed consistent data for all clients and data strictly only for
one client.

In my experience is for the last as long as it is not updated to the
database the "session" the best. While fore the first mentioned data (not
updated by the clients, by instance article names) a shared/static class.
The last because that kind of classes belongs to all users and are
persistent as long as there is one session. As Jon (codemeister) already
wrote is serializing very good for this.

The dataset as example is already serialized in memory (you can put it in a
session in one time). This approach needs of course that you use as small as
possible datasets and not complete datatables and that you update those as
soon as possible.

I hope this helps

Cor
 
Good question, I would persist the data to a box/database which contains
other critical system wide data, and if it goes down the whole
country/system is down. Then I have a single point to worry about????
 
Jim Douglas said:
Good question, I would persist the data to a box/database which contains
other critical system wide data, and if it goes down the whole
country/system is down. Then I have a single point to worry about????
Click to expand...

Yes, you do have a single point of failure at that point - for better
or worse. (The "better" is only that you're likely to get more help
keeping the system up if other people absolutely need it too...)
 
Jim,
Good question, I would persist the data to a box/database which contains
other critical system wide data, and if it goes down the whole
country/system is down. Then I have a single point to worry about????
Click to expand...
With this you acknowledge only what I wrote. Update data as soon as it is
possible in a database. However session data is raw data in fact not ready
to see as real data, ready for an update, because the status is unknown.

Saving that and using that after a system down, can be for me even be more
dangerous. The client did not acknowledge it as true and you probably don't
know the status, because at that moment that the status would be saved the
system was going down.

Just my thought,

Cor
 
Back
Top