Caching ViewState

[Kikoz]

Hi all.

I override Page's SavePageStateToPersistenceMedium(...) and
LoadPageStateFromPersistenceMedium() methods to keep page's ViewState on the
server. Very well documented approach, nothing fancy here. I use my own
custom session implementation for all users who log into the app. Each such
session has its encrypted unique string, blah blah... If I store ViewState
of each request on the server, I have to have a way to find correct
ViewState when user posts back. I didn't invented any weels when I decided
to use a combination of that unique sessionID and a path of requested file.
Together they make a perfect key that uniquely describes the "who" and
"where". Now. I decided to use Cache as a storage for ViewState. It was
working beautifully while I was developing this app on my localhost spending
average 0.003 sec to load and deserialize ViewState from Cache. I was
imitating dozens of concurrent users, etc. Was working. Then I delpoyed this
thing to the remote server (some hosting). On that server very often (every
5th or so request) I had an exception saying something like "corrupted
viewstate, do you use a farm?, blah blah". Hosting company swears they don't
use any farms, just RAID. Then I deployed this app on another remote server.
Same thing. Then I used hard drive to store ViewState there instead of Cache
and everything was back to normal again on all machines except that now it
was spending 0.04 secs to load ViewState. I red some stuff about MachineKey
but they talk about farms and gardens. The average size of one ViewState
encrypted text is 10 - 20 kb. Does size matter?

Why Cache scenario works fine on my local host and fails on remote
machines?? I can use Application for this, of course, because I can uniquely
identify a user, but I'd like to use "expiration" feature of Cache wich I'd
have to implement by myself in case of Application.

I would greatly appreciate any kind of help!!

Kikoz.

 

[bruce barker]

when you use the cache, there is no guarantee that it will be kept. any
constraint on memory will cause the cache to be flushed. on your local box,
you are just running one web site, on the hosting server, there are more
than one, and the cache cannot grow as much.

you can use both, write the file and store in cache. if not in cache , read
from file. you could also store the viewstate in the session.

-- bruce (sqlwork.com)



| Hi all.
|
| I override Page's SavePageStateToPersistenceMedium(...) and
| LoadPageStateFromPersistenceMedium() methods to keep page's ViewState on
the
| server. Very well documented approach, nothing fancy here. I use my own
| custom session implementation for all users who log into the app. Each
such
| session has its encrypted unique string, blah blah... If I store ViewState
| of each request on the server, I have to have a way to find correct
| ViewState when user posts back. I didn't invented any weels when I decided
| to use a combination of that unique sessionID and a path of requested
file.
| Together they make a perfect key that uniquely describes the "who" and
| "where". Now. I decided to use Cache as a storage for ViewState. It was
| working beautifully while I was developing this app on my localhost
spending
| average 0.003 sec to load and deserialize ViewState from Cache. I was
| imitating dozens of concurrent users, etc. Was working. Then I delpoyed
this
| thing to the remote server (some hosting). On that server very often
(every
| 5th or so request) I had an exception saying something like "corrupted
| viewstate, do you use a farm?, blah blah". Hosting company swears they
don't
| use any farms, just RAID. Then I deployed this app on another remote
server.
| Same thing. Then I used hard drive to store ViewState there instead of
Cache
| and everything was back to normal again on all machines except that now it
| was spending 0.04 secs to load ViewState. I red some stuff about
MachineKey
| but they talk about farms and gardens. The average size of one ViewState
| encrypted text is 10 - 20 kb. Does size matter?
|
| Why Cache scenario works fine on my local host and fails on remote
| machines?? I can use Application for this, of course, because I can
uniquely
| identify a user, but I'd like to use "expiration" feature of Cache wich
I'd
| have to implement by myself in case of Application.
|
| I would greatly appreciate any kind of help!!
|
| Kikoz.
|
|