Dont want to throw a rench at what we have so far, but, as I get more
familiar with what you are trying to do, I get different thoughts about how
to go about doing it.
You might want to consider output cache/partial output caching on the detail
page. This will be the most effective and trouble-free implementation if (a)
the data can stay stale for X amount of time (say 10 minutes) and (b) the
same detail page will get hit more than once within that X minute.
The same applies for the results page. How many search parameters are there?
Is it likely that the same query will happen within X seconds by another
user? If it ISN'T, then caching it globally to all users doesn't make the
most sense.
If you are dealing with a relatively small amount of data, you could hold
all the search results in-memory and query directly against the in-memory
store. This means you only go to the database when the cache is dropped to
get all items back.
If you are dealing with many records, the likely hood of an item being
retrieved from the cache before it expires is small. In this case,all you
are really worried about is caching for the 1 user going back and forth
between details and results.
Your use of mySessionId as the key is fine. If you want to cache multiple
things for the user, say multiple pages of the result, you'll need to stick
it to a made-up key, like "page1: + mySessionId;
To make your business layer truly reusable, ur better off using
HttpRuntime.Cache (although that's really a very minor point).
You should also write it like this:
DataTable myTable = (DataTable) HttpContext.Current.Cache[mySessionId];
if (myTable == null)
{
myTable =GetTableSomehow();
HttpContext.Current.Cache.Insert(mySessionId,myTab le ) ;
}
return myTable;
doing it the way you did, there's a chance for a weird nullreferenceerror...
This is what you have:
if (HttpContext.Current.Cache[mySessionId]==null)
{
HttpContext.Current.Cache.Insert(mySessionId,myDat atable) ;
// *** RIGHT HERE the item could be dumped from the cache!! *///
}
return (DataTable) HttpContext.Current.Cache[mySessionId];
My way, you've established a strong reference to the data (via the myTable)
reference.
Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Stan SR" <> wrote in message
news:eQ$QhRZ%...
> Karl and Samuel,
>
> Many thanks for your help.
> It seems the Cache solution is better for my needs than session.
> When you say to use a smart cachekey, does it mean, I could do something
> like
>
> if (HttpContext.Current.Cache[mySessionId]==null)
> HttpContext.Current.Cache.Insert(mySessionId,myDat atable) ;
> return (DataTable) HttpContext.Current.Cache[mySessionId];
> I think I try to use this method, but it didn't work. Do I miss something
> ?
>
> As you ve said, Karl, I use a Business Layer, (that's why I use
> HttpContext.Current.Cache).
>
>
> About the HttpContext.Items, do you think it should be the best approach ?
> I have a list of results and a details item page, and I want to navigate
> to the previous and next item from the detail page
> and of course go back to the result page ?
> So what I think, it's to cache the result (coming from a sql query) and
> use this cache for the list and details page.
> is it a good practice ?
>
> Stan
>
>
>
> Karl (or somebody else) if you could tell me how I have to work
>
>
>> HttContext.Current.Cache is a property of type
>> System.Web.Caching.Cache...
>>
>> You are getting an instance of a object and it's declaration mixed up.
>>
>> The Page object exposes a Cache property, so from a page, user control
>> or master page, youc an simply do:
>>
>> Cache.Insert(...)
>>
>> From a business layer, you can do HttpContext.Current.Cache
>>
>> HttContext.Current could be null though. So you can also use
>> HttpRuntime.Cache - which'll never be null, even in a non-web context.
>> They are all the same instance (it's a singleton as far as I know). So
>> you can intermix all of them.
>>
>> There are two main difference between sessions and Cache:
>> - The cache is global to all users
>> - The session guarantees (more or less) that the data will be there.
>>
>> As suggestion by Samuel, it's very easy to circumvent the first
>> difference by using a smart cachekey (say one that includes a sessionId).
>>
>> As for the 2nd one, a lot of us prefer the Cache over the session because
>> it allows .NET more flexibility in managing it's memory. You just need to
>> program more defensively, because a cache lookup might return null...
>>
>>
>> If you are only looking to store data from one page to another (like a
>> list and then a detail page), you could consider using the
>> HttpContext.Items collection and using a Server.Transfer. From what I
>> understand it's the best bet because it's the right scope - it's short
>> lived and per-user.
>>
>> Karl
>>
>> --
>> http://www.openmymind.net/
>> http://www.fuelindustries.com/
>>
>>
>> "Stan SR" <> wrote in message
>> news:%23LOhCqP%...
>>> Hi Samuel,
>>>
>>> I thank you for your reply.
>>> What is the difference with System.Web.Caching namespace and
>>> HttpContexte.Current.Cache ?
>>>
>>>
>>> For the second Part, I use a session variable and I store the datatable
>>> using this session.
>>>
>>> I don't know if it's a good idea..
>>>
>>> Stan
>>>
>>> "samuelhon"
>>>
>>>> Hi Stan
>>>>
>>>>> When I use this bit of code I get an error
>>>>> if (Cache["myUserList"]==null) Cache.Insert("myUserList",userlist);
>>>>> I don't know which namespace to use.
>>>>
>>>> In 2.0, its under System.Web.Caching
>>>>
>>>>> And, is it possible to create a Data Cache for each user
>>>>> I have a seach engine page that returns the result to another page.
>>>>> And I have a detail page for each item (like a simple catalog).
>>>>> I would like to navigate between each item and go back to the result
>>>>> page
>>>>> without requerying the database.
>>>>>
>>>>> Any advice ?
>>>>
>>>> It is possible to do this, you can use the session id as part of the
>>>> cache key.
>>>>
>>>> However, it might be a good idea to share all the caches. You can
>>>> create a key using all the search parameters so the results remain
>>>> unique
>>>>
>>>> Sam
>>>>
>>>
>>>
>>
>>
>
>
Similar Threads
