[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.aspnet.caching

Cache refresh

Ronnie R

1/30/2010 11:38:00 AM

Hi there

I have an application that has a one off db hungry task that takes 3 seconds
to run to great some information that I can store in Cache for all sessions.
This informaton is valid for the day, and so the cache expires for next day.

Currently, I check if Cache["fred"] exists, if it doesnt, run the task,
store the information in the Cache. For the sake of discussion if we can
assume that this works fine in my app, and the db query is efficient.

My question is, as this task takes 3 seconds, should I need to 'lock' the
Cache in any way to prevent a concurrent user that may hit the site within
the same 3 second period from rerunning the same task?

I realise that either way there is going to be a 3 second delay, but it
would be lighter on the db?

Any thoughts on this, with thoughts on the best implementation if valid
would be greatly apperciated.

Thanks!
3 Answers

Alvin Bruney

2/1/2010 1:03:00 AM

0

The lock on the cache does not prevent 'a concurrent user that may hit the
site within the same 3 second period from rerunning the same task'. The lock
is to prevent data corruption which can happen if the cache is being updated
at the same time that it is being read. A side effect of the lock is that
requesting threads will wait until the lock is free which has the intended
effect of preventing the other requestors from rerunning the same task.

That said, it's a very bad idea to to lock the cache object directly. The
reason is that the lock on the cache prevents even ASP.NET intrinsics from
accessing the cache store - everything grinds to a halt (this is not exactly
100% gospel true, but it is true enough for my explanation). Instead, you
should lock on a static object (string for instance) that represents the
cache. That is more efficient and permits ASP.NET intrinsics to access the
cache as needed.

Note: The reason why this is not 100% true is that ASP.NET intrinsics access
the cache data structures directly, they do not route via the Cache so a
lock doesn't affect them. However, the lock affects all ASP.NET pipeline
requests.

--
Vapordan
Shameless Author Plug
ASP.NET 4 by Example only $20
OWC Blackbook www.lulu.com/owc

"Ronnie R" <RonnieR@discussions.microsoft.com> wrote in message
news:511E264C-6B9D-4E03-A1C4-4C07A6E11BCB@microsoft.com...
> Hi there
>
> I have an application that has a one off db hungry task that takes 3
> seconds
> to run to great some information that I can store in Cache for all
> sessions.
> This informaton is valid for the day, and so the cache expires for next
> day.
>
> Currently, I check if Cache["fred"] exists, if it doesnt, run the task,
> store the information in the Cache. For the sake of discussion if we can
> assume that this works fine in my app, and the db query is efficient.
>
> My question is, as this task takes 3 seconds, should I need to 'lock' the
> Cache in any way to prevent a concurrent user that may hit the site within
> the same 3 second period from rerunning the same task?
>
> I realise that either way there is going to be a 3 second delay, but it
> would be lighter on the db?
>
> Any thoughts on this, with thoughts on the best implementation if valid
> would be greatly apperciated.
>
> Thanks!
>
>

Ronnie R

2/5/2010 2:16:00 PM

0

Hi Alvin

Thanks for taking the time to reply and sorry for not repsonding earlier

This is very useful information, thanks, i'm glad I asked. So the principle
of locking to prevent the task from rerunning is sound, but its the way I do
it is the issue, and locking something else rather than the cache itself is
the way. I hope I have understood this correctly. Thanks

"Alvin Bruney - ASP.NET MVP" wrote:

> The lock on the cache does not prevent 'a concurrent user that may hit the
> site within the same 3 second period from rerunning the same task'. The lock
> is to prevent data corruption which can happen if the cache is being updated
> at the same time that it is being read. A side effect of the lock is that
> requesting threads will wait until the lock is free which has the intended
> effect of preventing the other requestors from rerunning the same task.
>
> That said, it's a very bad idea to to lock the cache object directly. The
> reason is that the lock on the cache prevents even ASP.NET intrinsics from
> accessing the cache store - everything grinds to a halt (this is not exactly
> 100% gospel true, but it is true enough for my explanation). Instead, you
> should lock on a static object (string for instance) that represents the
> cache. That is more efficient and permits ASP.NET intrinsics to access the
> cache as needed.
>
> Note: The reason why this is not 100% true is that ASP.NET intrinsics access
> the cache data structures directly, they do not route via the Cache so a
> lock doesn't affect them. However, the lock affects all ASP.NET pipeline
> requests.
>
> --
> Vapordan
> Shameless Author Plug
> ASP.NET 4 by Example only $20
> OWC Blackbook www.lulu.com/owc
>
> "Ronnie R" <RonnieR@discussions.microsoft.com> wrote in message
> news:511E264C-6B9D-4E03-A1C4-4C07A6E11BCB@microsoft.com...
> > Hi there
> >
> > I have an application that has a one off db hungry task that takes 3
> > seconds
> > to run to great some information that I can store in Cache for all
> > sessions.
> > This informaton is valid for the day, and so the cache expires for next
> > day.
> >
> > Currently, I check if Cache["fred"] exists, if it doesnt, run the task,
> > store the information in the Cache. For the sake of discussion if we can
> > assume that this works fine in my app, and the db query is efficient.
> >
> > My question is, as this task takes 3 seconds, should I need to 'lock' the
> > Cache in any way to prevent a concurrent user that may hit the site within
> > the same 3 second period from rerunning the same task?
> >
> > I realise that either way there is going to be a 3 second delay, but it
> > would be lighter on the db?
> >
> > Any thoughts on this, with thoughts on the best implementation if valid
> > would be greatly apperciated.
> >
> > Thanks!
> >
> >

Alvin Bruney

2/14/2010 3:25:00 AM

0

Yup, that's about it.

--
Vapordan
Shameless Author Plug
ASP.NET 4 by Example only $20
OWC Blackbook www.lulu.com/owc

"Ronnie R" <RonnieR@discussions.microsoft.com> wrote in message
news:F0508827-A979-4D32-BD44-34FEF28DED98@microsoft.com...
> Hi Alvin
>
> Thanks for taking the time to reply and sorry for not repsonding earlier
>
> This is very useful information, thanks, i'm glad I asked. So the
> principle
> of locking to prevent the task from rerunning is sound, but its the way I
> do
> it is the issue, and locking something else rather than the cache itself
> is
> the way. I hope I have understood this correctly. Thanks
>
> "Alvin Bruney - ASP.NET MVP" wrote:
>
>> The lock on the cache does not prevent 'a concurrent user that may hit
>> the
>> site within the same 3 second period from rerunning the same task'. The
>> lock
>> is to prevent data corruption which can happen if the cache is being
>> updated
>> at the same time that it is being read. A side effect of the lock is that
>> requesting threads will wait until the lock is free which has the
>> intended
>> effect of preventing the other requestors from rerunning the same task.
>>
>> That said, it's a very bad idea to to lock the cache object directly. The
>> reason is that the lock on the cache prevents even ASP.NET intrinsics
>> from
>> accessing the cache store - everything grinds to a halt (this is not
>> exactly
>> 100% gospel true, but it is true enough for my explanation). Instead, you
>> should lock on a static object (string for instance) that represents the
>> cache. That is more efficient and permits ASP.NET intrinsics to access
>> the
>> cache as needed.
>>
>> Note: The reason why this is not 100% true is that ASP.NET intrinsics
>> access
>> the cache data structures directly, they do not route via the Cache so a
>> lock doesn't affect them. However, the lock affects all ASP.NET pipeline
>> requests.
>>
>> --
>> Vapordan
>> Shameless Author Plug
>> ASP.NET 4 by Example only $20
>> OWC Blackbook www.lulu.com/owc
>>
>> "Ronnie R" <RonnieR@discussions.microsoft.com> wrote in message
>> news:511E264C-6B9D-4E03-A1C4-4C07A6E11BCB@microsoft.com...
>> > Hi there
>> >
>> > I have an application that has a one off db hungry task that takes 3
>> > seconds
>> > to run to great some information that I can store in Cache for all
>> > sessions.
>> > This informaton is valid for the day, and so the cache expires for next
>> > day.
>> >
>> > Currently, I check if Cache["fred"] exists, if it doesnt, run the task,
>> > store the information in the Cache. For the sake of discussion if we
>> > can
>> > assume that this works fine in my app, and the db query is efficient.
>> >
>> > My question is, as this task takes 3 seconds, should I need to 'lock'
>> > the
>> > Cache in any way to prevent a concurrent user that may hit the site
>> > within
>> > the same 3 second period from rerunning the same task?
>> >
>> > I realise that either way there is going to be a 3 second delay, but it
>> > would be lighter on the db?
>> >
>> > Any thoughts on this, with thoughts on the best implementation if valid
>> > would be greatly apperciated.
>> >
>> > Thanks!
>> >
>> >