Database still hit when using StorageCache

Mar 26, 2009 at 8:21 PM

I noticed when using the StorageCache that there is still a database call that checks the Settings table. Here is an example of the SQL run during a StorageCache.CheckAccess call:

exec sp_executesql N'SELECT TOP 1 [t0].[SettingName], [t0].[SettingValue]
FROM [dbo].[Settings] AS [t0]
WHERE [t0].[SettingName] = @p0',N'@p0 nvarchar(4)',@p0=N'Mode'

Is it possible to make this cached as well so that NO database hits are made when making a CheckAccess call on the StorageCache object?

Mar 26, 2009 at 9:29 PM
As a follow up, I noticed that all "Get" accessors for Store, Application, Groups, etc; all do their own little "hit" to the database for the Settings table. Although this IS light and much better than querying for every object accessed, it is still a hit to the database that seems unnecessary, AND it is done multiple times ( 4 to be exact ) for one request to get an ApplicationGroup (essentially once at each level of the "tree"). It seems these settings wouldn't change all that often and would be better off cached along with everything else. Yes/No? Thoughts?

Thanks for your help!
Mar 27, 2009 at 8:31 AM

Hi archwaydev,

Settings are needed everytime because different settings may invalidate CheckAccess results.

Have you seen the NetSqlAzMan WCF Cache Service ?

The WCF cache service, cache all based on time-based policy and CheckAccess execution is a lot much faster.



Mar 27, 2009 at 8:33 AM
Edited Jul 21, 2009 at 12:50 PM

For a better cache, please try to use the WCF Cache Service.

It was done by this goal.




Andrea Ferendeles