469,626 Members | 904 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,626 developers. It's quick & easy.

How and why to save ViewState in a session object

I have a large ViewState and I've heard I can save the ViewState in a sesison
object. What are the advantages of doing so and how do I do it? I've been
told that I am gettign DNS timeouts because of the ViewState being too large.
I'm trying to avoid writing manual paging routines for now.
--
Tim
Aug 21 '06 #1
6 1910
Hi Tim,

View State can be customized to be stored in a Session or Cache object. It
is done by overriding the 'SavePageStateToPersistenceMedium' and
'LoadPageStateFromPersistenceMedium' methods. (see code snippet below)
protected override void SavePageStateToPersistenceMedium(Object viewState)
{
string _vskey;
_vskey = "VIEWSTATE_" + base.Session.SessionID + "_" + Request.RawUrl +
"_" + System.DateTime.Now.Ticks.ToString();

Cache.Add(_vskey, viewState, null,
System.DateTime.Now.AddMinutes(Session.Timeout), Cache.NoSlidingExpiration,
CacheItemPriority.Default, null);

RegisterHiddenField("_VIEWSTATE_KEY", _vskey);
}

protected override object LoadPageStateFromPersistenceMedium()
{
string _vskey = Request.Form["_VIEWSTATE_KEY"];

if (_vskey == null)
{
return null;
}
else
{
return Cache[_vskey];
}
}

Advantages: If the ViewState is large, it increases the page size
considerably and results in an increase in response time (page load time).
Saving the ViewState to a session/cache can result in an improved response
time (page size is reduced considerably). On the other hand, it can consume
server resources (which can be handled by improving the hardware).

Regards,
Augustin


"AAOMTim" wrote:
I have a large ViewState and I've heard I can save the ViewState in a sesison
object. What are the advantages of doing so and how do I do it? I've been
told that I am gettign DNS timeouts because of the ViewState being too large.
I'm trying to avoid writing manual paging routines for now.
--
Tim
Aug 21 '06 #2
Here is a link (http://www.eggheadcafe.com/articles/20040613.asp) to a
customised persistence mechanism that we implement recently.

A number of our customers share 512/128 DSL connections between a number of
staff, and the posting back of large viewstates was causing significant
performance issues for them.

We choose to store the viewstate in a SQL store, and although this incurs an
extra database hit, that hit is significantly less than the round trip of a
large viewstate to the browser and back.
<DIV>&quot;AAOMTim&quot; &lt;AA*****@discussions.microsoft.com&gt; wrote in
message news:3E**********************************@microsof t.com...</DIV>>I
have a large ViewState and I've heard I can save the ViewState in a sesison
object. What are the advantages of doing so and how do I do it? I've
been
told that I am gettign DNS timeouts because of the ViewState being too
large.
I'm trying to avoid writing manual paging routines for now.
--
Tim
Aug 21 '06 #3
Thank you for your response. Can you discuss the merits of saving to a Cache
object instead of to a Session?
--
Tim
"Augustin Prasanna" wrote:
Hi Tim,

View State can be customized to be stored in a Session or Cache object. It
is done by overriding the 'SavePageStateToPersistenceMedium' and
'LoadPageStateFromPersistenceMedium' methods. (see code snippet below)
protected override void SavePageStateToPersistenceMedium(Object viewState)
{
string _vskey;
_vskey = "VIEWSTATE_" + base.Session.SessionID + "_" + Request.RawUrl +
"_" + System.DateTime.Now.Ticks.ToString();

Cache.Add(_vskey, viewState, null,
System.DateTime.Now.AddMinutes(Session.Timeout), Cache.NoSlidingExpiration,
CacheItemPriority.Default, null);

RegisterHiddenField("_VIEWSTATE_KEY", _vskey);
}

protected override object LoadPageStateFromPersistenceMedium()
{
string _vskey = Request.Form["_VIEWSTATE_KEY"];

if (_vskey == null)
{
return null;
}
else
{
return Cache[_vskey];
}
}

Advantages: If the ViewState is large, it increases the page size
considerably and results in an increase in response time (page load time).
Saving the ViewState to a session/cache can result in an improved response
time (page size is reduced considerably). On the other hand, it can consume
server resources (which can be handled by improving the hardware).

Regards,
Augustin


"AAOMTim" wrote:
I have a large ViewState and I've heard I can save the ViewState in a sesison
object. What are the advantages of doing so and how do I do it? I've been
told that I am gettign DNS timeouts because of the ViewState being too large.
I'm trying to avoid writing manual paging routines for now.
--
Tim
Aug 21 '06 #4
Thanks for the response. How would you compare the efficiency of saving your
ViewState to a SQL Store as compared to saving it to Cache?
--
Tim
"Dave Moyle" wrote:
Here is a link (http://www.eggheadcafe.com/articles/20040613.asp) to a
customised persistence mechanism that we implement recently.

A number of our customers share 512/128 DSL connections between a number of
staff, and the posting back of large viewstates was causing significant
performance issues for them.

We choose to store the viewstate in a SQL store, and although this incurs an
extra database hit, that hit is significantly less than the round trip of a
large viewstate to the browser and back.
<DIV>"AAOMTim" <AA*****@discussions.microsoft.comwrote in
message news:3E**********************************@microsof t.com...</DIV>>I
have a large ViewState and I've heard I can save the ViewState in a sesison
object. What are the advantages of doing so and how do I do it? I've
been
told that I am gettign DNS timeouts because of the ViewState being too
large.
I'm trying to avoid writing manual paging routines for now.
--
Tim

Aug 21 '06 #5
Hi Tim

When we looked at the article I mentioned, we saw that using the cache was
perhaps the most efficient custom store.

For us the potential memory footprint of using the cache was a risk and as a
result we didn't even test the real world response times using the cache. We
run multiple servers in a farm and so our application already used SQL as
the session store, and that gave us immediate scalability.

As I mentioned previously, the saving we made just using the SQL store was
significant, so we have not had the need to try and squeeze any blood from
the stone if you will.

Dave

<DIV>&quot;AAOMTim&quot; &lt;AA*****@discussions.microsoft.com&gt; wrote in
message news:80**********************************@microsof t.com...</DIV>>
Thanks for the response. How would you compare the efficiency of saving
your
ViewState to a SQL Store as compared to saving it to Cache?
--
Tim
"Dave Moyle" wrote:
>Here is a link (http://www.eggheadcafe.com/articles/20040613.asp) to a
customised persistence mechanism that we implement recently.

A number of our customers share 512/128 DSL connections between a number
of
staff, and the posting back of large viewstates was causing significant
performance issues for them.

We choose to store the viewstate in a SQL store, and although this incurs
an
extra database hit, that hit is significantly less than the round trip of
a
large viewstate to the browser and back.
<DIV>"AAOMTim" <AA*****@discussions.microsoft.comwrote in
message
news:3E**********************************@microso ft.com...</DIV>>I
have a large ViewState and I've heard I can save the ViewState in a
sesison
object. What are the advantages of doing so and how do I do it? I've
been
told that I am gettign DNS timeouts because of the ViewState being too
large.
I'm trying to avoid writing manual paging routines for now.
--
Tim

Aug 21 '06 #6
Tim,

Cache is a more efficient way of persisting data on the server side. It
exposes many properties that can be used to control the manner in which data
is cached. More than that, if the resources are low, runtime can purge some
of the items that are stored in the cache (which will not happen when session
is used) you can find lots of articles on cache and it's features.

Regards,
Augustin
http://augustinprasanna.blogspot.com

"AAOMTim" wrote:
Thank you for your response. Can you discuss the merits of saving to a Cache
object instead of to a Session?
--
Tim
"Augustin Prasanna" wrote:
Hi Tim,

View State can be customized to be stored in a Session or Cache object. It
is done by overriding the 'SavePageStateToPersistenceMedium' and
'LoadPageStateFromPersistenceMedium' methods. (see code snippet below)
protected override void SavePageStateToPersistenceMedium(Object viewState)
{
string _vskey;
_vskey = "VIEWSTATE_" + base.Session.SessionID + "_" + Request.RawUrl +
"_" + System.DateTime.Now.Ticks.ToString();

Cache.Add(_vskey, viewState, null,
System.DateTime.Now.AddMinutes(Session.Timeout), Cache.NoSlidingExpiration,
CacheItemPriority.Default, null);

RegisterHiddenField("_VIEWSTATE_KEY", _vskey);
}

protected override object LoadPageStateFromPersistenceMedium()
{
string _vskey = Request.Form["_VIEWSTATE_KEY"];

if (_vskey == null)
{
return null;
}
else
{
return Cache[_vskey];
}
}

Advantages: If the ViewState is large, it increases the page size
considerably and results in an increase in response time (page load time).
Saving the ViewState to a session/cache can result in an improved response
time (page size is reduced considerably). On the other hand, it can consume
server resources (which can be handled by improving the hardware).

Regards,
Augustin


"AAOMTim" wrote:
I have a large ViewState and I've heard I can save the ViewState in a sesison
object. What are the advantages of doing so and how do I do it? I've been
told that I am gettign DNS timeouts because of the ViewState being too large.
I'm trying to avoid writing manual paging routines for now.
--
Tim
Aug 23 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by JezB | last post: by
4 posts views Thread by Ralph Krausse | last post: by
1 post views Thread by Edward Yang | last post: by
6 posts views Thread by clsmith66 | last post: by
3 posts views Thread by MattC | last post: by
6 posts views Thread by mosscliffe | last post: by
1 post views Thread by Irene | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.