views:

1040

answers:

3

what happens if an user trying to read HttpContext.Current.Cache[key] while the other one trying to remove object HttpContext.Current.Cache.Remove(key) at the same time?

Just think about hundreds of users reading from cache and trying to clean some cache objects at the same time. What happens and is it thread safe?

Is it possible to create database aware business objects in cache?

+1  A: 

The built-in ASP.Net Cache object (http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx) is thread-safe, so insert/remove actions in multi-threaded environments are inherently safe.

Your primary requirement for putting any object in cache is that is must be serializable. So yes, your db-aware business object can go in the cache.

jro
Just because the object is thread safe, does not guarantee that the object will be locked or available, and Serializable has nothing to do with a DB aware object
StingyJack
Correct, thread-safety does not protect against deadlocks. The HttpRuntime Cache does, however, have built-in protection to ensure availability.But *any* object that goes into the Cache must be serializable. My point is that DB-awareness for an object in cache is inconsequential.
jro
Agreed. Thanks for clarifying.
StingyJack
+1  A: 

If the code is unable to get the object, then nothing / null is returned.

Why would you bother to cache an object if you would have the chance of removing it so frequently? Its better to set an expiration time and reload the object if its no longer in the cache.

Can you explain "DB aware object"? Do you mean a sql cache dependency, or just an object that has information about a db connection?

EDIT: Reponse to comment #3.

I think we are missing something here. Let me explain what I think you mean, and you can tell me if its right.

  1. UserA checks for an object in cache ("resultA") and does not find it.
  2. UserA runs a query. Results are cached as "resultA" for 5 minutes.
  3. UserB checks for an object in cache ("resultA") and does find it.
  4. UserB uses the cached object "resultA"

If this is the case, then you dont need a Sql Cache dependency.

StingyJack
I mean something like sql cache dependency.
Erhan
I would recommend against that if the sql data is frequently updated. You run the risk of implementing a potential performance problem if its too frequent, or if several object share a similar dependency.
StingyJack
I want to cache query results simultaneously cause of sql query overhead on db server.
Erhan
Erhan
Its not that it will be broken, but a sql dependency will force extra queries and load on your database because its always checking.
StingyJack
A: 

Well i have a code to populate cache:

string cacheKey = GetCacheKey(filter, sort);
if (HttpContext.Current.Cache[cacheKey] == null)
{
  reader = base.ExecuteReader(SelectQuery);
  HttpContext.Current.Cache[cacheKey] = 
    base.GetListByFilter(reader, filter, sort);
}
return HttpContext.Current.Cache[cacheKey] as List<CurrencyDepot>;

and when table updated cleanup code below executing:

private void CleanCache()
{
  IDictionaryEnumerator enumerator = 
    HttpContext.Current.Cache.GetEnumerator();
  while (enumerator.MoveNext())
  {
    if (enumerator.Key.ToString().Contains(_TableName))
    {
      try {
        HttpContext.Current.Cache.Remove(enumerator.Key.ToString());
      } catch (Exception) {}
    }
  }
}

Is this usage cause a trouble?

Erhan
Yes. Don't enumerate through cache items, and dont swallow an exception like that.
StingyJack
What's the problem with enumeration of cache items?
Erhan
You dont need to. Checking for the item is as simple as "if (Cache[_tableName] != null)" .
StingyJack
CleanCache is data access layer function and processing cache objects depending on tablename. Enumeration needed cause of hash algorithmic Cache Keys (e.g. Cache[Order|8CA12010])
Erhan