Note that there are some explanatory texts on larger screens.

plurals
  1. POSystem.Runtime.Caching "forgets" about caching when the debugger is attached
    primarykey
    data
    text
    <p>I have a suite of application components that require the persistence of a large business object collection in order to achieve reasonable performance. This is essentially data that is read from the database and hydrated into objects for later reuse.</p> <p>This object collection was originally implemented in .net 3.5, so In order to achieve this persistence when loaded by an ASP.Net runtime the HttpRuntime.Cache was used, and if it was loaded by a win forms client the enterprise library caching block was used.</p> <p>Now, with .net 4.0 the System.Runtime.Caching is available for these requests. The following pattern was implemented for cached item get. </p> <pre><code>Public Function GetCachedObject(cacheKey as String) as Object Dim _returnValue as Object SyncLock m_lockObject //some private lock object Dim _cache as ObjectCache = MemoryCache.Default //This is never found when debugging If _cache.Item(cacheKey) IsNot Nothing Then _returnValue = _cache.Item Else Dim _policy As New System.Runtime.Caching.CacheItemPolicy() _policy.AbsoluteExpiration = DateTime.Now.AddHours(12) Dim _obj as Object = MethodToGetAndHydrateObject() _cache.Add(New CacheItem(cacheKey, _obj), _policy) _returnValue = _obj End If End SyncLock Return _returnValue End Function </code></pre> <p>This seems to work, <strong>but only as long as there is no debugger (vs2010) attached</strong>. </p> <p>Once I attach a debugger, the cache existence check noted above always returns nothing.</p> <p>These are pretty much rote examples of how to use the cache from MSDN. Is there something that I am missing, or is this truly unexpected behavior?</p> <p>Update: I see this happening when the components are hosted in ASP.net. I can build the DLL's, copy them to the site, run a few executions of steps and its fine. As soon as I attach the debugger and execute the steps again, it displays this behavior.</p> <p><strong>Update 2</strong>: As often happens here, a little while after I posted the question, I got a bit more error detail from the debugger output window. This error detail led me to <a href="http://connect.microsoft.com/VisualStudio/feedback/details/675188/a-memorycache-hosted-in-asp-net-sometimes-breaks-in-its-timer-callback-to-update-the-cache-size" rel="nofollow">this</a> MS Connect article. It turns out that when using remoting (I am) to call into an ASP.NET hosted app, the MemoryCache.Default seems to tie its janitorial timers (cache cleanup, etc) to a thread context. When the thread context is no longer available, the callbacks fail and the MemoryCache.Default appears to stop working for all other attempts.</p> <p>Adding the ExecutionContext.SuppressFlow() (as seen in the reworked example below) seems to stop this attachment.</p> <pre><code> Using ExecutionContext.SuppressFlow() _cache = MemoryCache.Default End Using </code></pre> <p>I put this in yesterday and its been peachy since. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload