Which Method For Session???

[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

[CodeMeister]

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" <ja***********@genesis-software.com> wrote in message
news:F5********************@comcast.com...

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

[Jon Skeet [C# MVP]]

Jim Douglas <ja***********@genesis-software.com> wrote:

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?

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

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

[Jim Douglas]

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????

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Jim Douglas <ja***********@genesis-software.com> wrote:

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?

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jim Douglas <ja***********@genesis-software.com> wrote:

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????

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...)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

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????

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