Sql server session state - Serializing the System.XML.XmlDocument

[Guest]

I am implementing the Session state persistence to the Sql server in an
application which all this while was using InProc session state. One of the
pre-requisite of Sql server mode session state is that all the objects put
into the session should be serializable. The problem is the class which I am
marking as serializable is having System.XML.XmlDocument object as a member
variable. And Sql server mode requires that this System.XML.XmlDocument
should also be serialized as this is the part of the object I am putting in a
session. I see that XMLDocument is not marked as Serializable. Also the
session object its XMLDocument member variable is being used throughout the
existing application.So I would not like much changes which would break the
client code using this object.Does anybody see any workaround or I am missing
anything here?


Thank you in advance for the responses,
Ashish Gupta

 

[Guest]

to be honest you shouldn't really be putting complex types into session state
you should only store simple types or light weight business entities (DTO's)
not objects like XmlDocument.

HTH

Ollie Riches

 

[Nicholas Paldino [.NET/C# MVP]]

Ashish,

I think the best way to go would be to use custom serialization. If the
class is not too big, you can persist the XmlDocument to a string and then
just store that value when serializing the instance. Then, when
deserializing, you can just pull that from the SerializationInfo instance.

Or, if you want to get really fancy, you can use the OnSerializing
attribute applied to a method. This method would have one parameter of type
StreamingContext. You would then add a string field to your class which
stores the XML, and mark the XmlDocument field as NonSerializable. In your
method where the OnSerializing attribute is attached, you would save the
XmlDocument state in the new string field.

Then, you would add an OnDeserialized attribute to a method with the
same signature. In that method, you would take the value from the string
field, and create your XmlDocument.

 

[Nicholas Paldino [.NET/C# MVP]]

Ollie,

Why is that? Is it because it is not an in-proc session state, or is it
more of a general design guideline? If it is the latter, I would be
interested in hearing the reasoning behind it. On the surface, to me,
session state is the same as say, storing state in fields on a class derived
from Form (in Windows Forms, and yes, this is an overly simplistic
comparison). Why shouldn't it be complex?

 

[Guest]

I suppose the direction I am coming from is I have seen objects with large
memory footprints stored in out-of-proc session state when only a subset of
the fields available were actually required.

Small point I grant you but it is the princple I suppose - why waste
resources etc...

We can always get 'Mr Arnold' into the discussion if you want to 'spice' up
the discusson.

Ollie Riches

Ollie,

Why is that? Is it because it is not an in-proc session state, or is it
more of a general design guideline? If it is the latter, I would be
interested in hearing the reasoning behind it. On the surface, to me,
session state is the same as say, storing state in fields on a class derived
from Form (in Windows Forms, and yes, this is an overly simplistic
comparison). Why shouldn't it be complex?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

to be honest you shouldn't really be putting complex types into session
state
you should only store simple types or light weight business entities
(DTO's)
not objects like XmlDocument.

HTH

Ollie Riches

 

[Nicholas Paldino [.NET/C# MVP]]

I agree with that, I just thought it was presented more as a broad
recommendation for any session state. I would agree that when using
out-of-proc session state, that you have to be aware of things like this,
but not for in-proc session state.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I suppose the direction I am coming from is I have seen objects with large
memory footprints stored in out-of-proc session state when only a subset
of
the fields available were actually required.

Small point I grant you but it is the princple I suppose - why waste
resources etc...

We can always get 'Mr Arnold' into the discussion if you want to 'spice'
up
the discusson.

Ollie Riches

Ollie,

Why is that? Is it because it is not an in-proc session state, or is
it
more of a general design guideline? If it is the latter, I would be
interested in hearing the reasoning behind it. On the surface, to me,
session state is the same as say, storing state in fields on a class
derived
from Form (in Windows Forms, and yes, this is an overly simplistic
comparison). Why shouldn't it be complex?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

to be honest you shouldn't really be putting complex types into session
state
you should only store simple types or light weight business entities
(DTO's)
not objects like XmlDocument.

HTH

Ollie Riches

:

I am implementing the Session state persistence to the Sql server in
an
application which all this while was using InProc session state. One
of
the
pre-requisite of Sql server mode session state is that all the objects
put
into the session should be serializable. The problem is the class
which I
am
marking as serializable is having System.XML.XmlDocument object as a
member
variable. And Sql server mode requires that this
System.XML.XmlDocument
should also be serialized as this is the part of the object I am
putting
in a
session. I see that XMLDocument is not marked as Serializable. Also
the
session object its XMLDocument member variable is being used
throughout
the
existing application.So I would not like much changes which would
break
the
client code using this object.Does anybody see any workaround or I am
missing
anything here?


Thank you in advance for the responses,
Ashish Gupta

 

[Guest]

Reading the comment diatribe, I would offer this:
The abuse of Session State in ASP.NET is legion, because it is so easy to
use. When you start with SQL Server Session State mode, this becomes
multiplied because of all the serilization and glop that needs to go over the
wire.
Questions: Do I really need to store an entire XmlDocument object in
Session? Is there an elegant way I can do it without relying on Session at
all?
Cheers,
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com