You should look into caching your data in the ASP.Net Cache. When you
add the item to cache, you can specify a duration and a method to call
when the cached value expires. Then you can reload the data in the
background without affecting the users.
Bryan Phillips
MCSD, MCDBA, MCSE
Blog: http://bphillips76.spaces.live.com
> Here's my scenario. Please advise me if you can.
>
[quoted text clipped - 33 lines]
>
> Again, any advice would be appreciated.
Bryan,
I am quite familiar with caching, but I'm not sure this will work. The
data I'm retrieving is specific to each user. This is why I'm choosing
cookies as my data store. I can temporarily (until the next
request/response cycle) place these somewhere else, as long as I can
get back to the values in the next cycle. In order to scope these to
the current user, session variables seemed like the logical answer, but
this doesn't appear to work under these conditions. I'm willing to
entertain other solutions as well.
Again the heart of the problem is that the data retrieval may take a
while to complete. I am requesting this data asynchronously so the
user is not impacted. However the callback may not be invoked until
after the response has been streamed to the user. Is there some place
I can store the data that will be in the user's scope on the next
request/response cycle?
> You should look into caching your data in the ASP.Net Cache. When you
> add the item to cache, you can specify a duration and a method to call
[quoted text clipped - 42 lines]
> >
> > Again, any advice would be appreciated.
carrolky - 27 Oct 2006 19:14 GMT
Eureka! I've got it.
Apparently there is a feature of ASP.Net such that if there is no value
stored in session state, there is nothing saved on the server. This
makes sense when you think about it. Why allocate storage space to a
session with nothing in it? Apparently the decision to not store
values is made before my callback function. Despite that I was able to
write values to session variables in the callback function, these were
not available when the next request cycle began.
I've read several articles that discuss this behavior under other
symptoms. Typically those involved lost session variables. In each of
those cases, the session id was different from one request/response
cycle to the next. In my case, the session ID was the same every time,
but the variables were not present if the asynchronous callback
occurred after the response had been sent to the client.
The solution in this case was to add a dummy session variable just
prior to firing the asynchronous call (Application.Session["DUMMY"] =
String.Empty;). This ensures that the session has some state
information and causes the decision to preserve the session state to be
true. The acutal saving (I assume) does not occur until the session is
about to be destroyed. When my callback function is invoked, I am able
to retrieve the reference to my session that I had stored in the
AsyncState. I can then write my additional variables to the session
state. Now however, these values are present when the next request
cycle begins. I have additional code that checks for the presence of
these variables on the next request to this session. If they are
present, they are added to cookies that will not expire for a week,
avoiding the need to repeat this lengthy process for some time.
Hope this helps someone.
> Bryan,
>
[quoted text clipped - 60 lines]
> > >
> > > Again, any advice would be appreciated.