RE: Session management on web farm with sql server

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks for your followup Bill,

For serialization, since winform/desktop application can hold most objects
in memory while ASP.NET web application is stateless(request, response
based) and may work between client and server machines, serialization plays
more important role here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
From: =?Utf-8?B?d2R1ZGVr?= <wdudek@xxxxxxxxxxxxxxxx>
References: <9E5A2E55-EA73-475D-A7E0-29C503F212D8@xxxxxxxxxxxxx>
<1D85C258-6104-4E4A-9F18-050635B2909D@xxxxxxxxxxxxx>
<A1F1F814-7CB8-43CB-A481-5902580998E3@xxxxxxxxxxxxx>
<bLKqzIpeIHA.360@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: Session management on web farm with sql server
Date: Fri, 29 Feb 2008 08:56:04 -0800


Thanks,

There isn't much out there regarding this problem. My background is
more
windows oriented than web, but it seems that if web sites really are going
to
replace the desktop application as allot of people would have you believe
that this particular issue would come up more often. Just my 2 cents, but
thanks again for the links I'll take a look.

Bill

""Steven Cheng"" wrote:

Hi Bill,

For binary serialization and implement your custom serialization
approach,
here are some reference that should be helpful:

#Run-time Serialization
http://msdn.microsoft.com/msdnmag/issues/02/04/net/

#Serialization in the .NET Framework
http://www.15seconds.com/issue/020903.htm


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no
rights.

--------------------
From: =?Utf-8?B?d2R1ZGVr?= <wdudek@xxxxxxxxxxxxxxxx>
References: <9E5A2E55-EA73-475D-A7E0-29C503F212D8@xxxxxxxxxxxxx>
<1D85C258-6104-4E4A-9F18-050635B2909D@xxxxxxxxxxxxx>
Subject: RE: Session management on web farm with sql server
Date: Thu, 28 Feb 2008 10:57:02 -0800


Thanks,
This explains exactly what is happening. I can look this up, but is
anyone aware of any links that discuss this issue in more depth? I
understand
the concept of custom serialization but have never worked with it.

Thanks again

Bill

"bruce barker" wrote:

session is a collection of objects. with in proc, this collection is
a
static
collection. with out-of-proc session managers (like sqlsession), the
session
collection is an instance collection tired to the request. at the end
of
the
request, it serialized out to the store. at the start of the request,
its
deserialied from the store. during request processing, there is no
difference
between inproc and out-of-proc sessions.

if you see a difference. then you object is not
serializing/deserializing
correctly. you will have to fix the logic. the most common issue, is
not
handling mulitple to references to the same object correctly.

simple example:

// first request

myObject obj = new myObject();
List<myObject> list = new List<myObject>();
list.Add(obj);
list.Add(obj);
Session["list"] = list;
list[0].Value="1"; // list[0].Value == list[1].Value == "1";
list[0].Value="2"; // list[0].Value == list[1].Value == "2";


// next request

List<myObject> list = (myObject) Session["list'];
list[0]="3"; // list[0].Value != list[1].Value

this is because at serialzztion time list[0] & list[1] where
deserialized.
when deserialiezed, two objects were created, but each with the same
value.
now changing one does not change the other.

so, if your object has mutiple refences to the same object (say the
same
object is in two collections) then you have to write a custom
serializer.

the approach i use for complex objects I store in session, is there
is a
base collection that objects belong to, and other references just
serialize
the lookup key.

-- bruce (sqlwork.com)


"wdudek" wrote:

We have a website that works fine when hosted on a single server,
however
it experiences some strange problems when run on a web farm using
SQL
Server
to handle session state. When running on the farm, in the same
method
call an
object that just had a value set will no longer have the value set
a
couple of lines later. In this example the object is pulled out of
session,
altered and placed back in session before a following line of code
tries to
use
the altered value, only to find out that it appears to have never
been
changed. The application essentially stores 1 object that contains
several
other
objects in session. The group that manages teh web farm is telling
me
that
this is the problem. They are saying that because of the
serialization/deserialization in sql server, the reference to the
inner
objects isn't flowing through to the object being stored in SQL
Server. Does
this sound correct? Should there be any differance between how a
website code
funcitons on a single server versus a web farm? They provided me
with
the
below documentation, but have not yet been able to tell me where it
came
from. This has been an ongoing battle over who's problem it really
is,
any
information on this subject will be appreciated. Also as a note all
of
the
objects are serializable.

Thanks,

Bill

This is the reponse I got from our techincal support group There is
no
problem with the SQL Server settings for storing the session as
session
objects get created, retrieved and updated in the SQL Server. The
issue is
with the way the session object is updated in the C# code.

Session in asp.net behaves as follows.

InProc: In this mode session data is stored in the AppDomain of the
application. All the objects stored in the session are actually
stored
in
AppDomain and a reference is created for the session.

SQL Server/State Server: In this mode session data is serialized
and
stored
in SQL server database. When sessions is loaded system will fetch
the
data
from database and deserialize it and creates the objects with
deserialize
data and bind them to state bag. In this mode the actual object
references
and session object references are different.

Because of this, the S&S application is able to retrieve data when
session
is in InProc but not in SQL Server. What's happening in S&S
application is
as
below.

In case of InProc session Inquiry object and Search
object
have
same reference, so updating one object is will show effect all its
references.

In case of SQL Server session each object will have its
own
reference (each time new object is created from deserialize data),
so
updating one object will not update the other object in the session.

To solve this, C# code needs to be modified where the session
related
objects are updated such that it gets updated in the session
correctly.








.

Relevant Pages

  • Session management on web farm with sql server
    ... it experiences some strange problems when run on a web farm using SQL Server ... In this example the object is pulled out of session, ... AppDomain and a reference is created for the session. ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: Session management on web farm with sql server
    ... For binary serialization and implement your custom serialization approach, ... objects in session. ... serialization/deserialization in sql server, the reference to the ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: Session management on web farm with sql server
    ... For binary serialization and implement your custom serialization approach, ... objects in session. ... serialization/deserialization in sql server, the reference to the ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Problem with Windows 2003 TS and SQL connection
    ... Do you get any message on the screen when the connection is lost? ... And connect to a file share on the SQL server? ... ending the TS session? ...
    (microsoft.public.windows.terminal_services)
  • RE: Session management on web farm with sql server
    ... the concept of custom serialization but have never worked with it. ... with out-of-proc session managers, ... handling mulitple to references to the same object correctly. ... it experiences some strange problems when run on a web farm using SQL Server ...
    (microsoft.public.dotnet.framework.aspnet)