Caching Pattern

jgk1701 posted on Monday, October 01, 2007

You will have to forgive this question as I am not experienced with multi-threading. I have been using the caching pattern outlined in the VB 2005 book on pages 405, 453, and 454. I am confused as to why the code in the GetList and InvalidateCache methods are not within Synclock blocks. I can see how this would not be an issue on the client side, but on the server side couldn't multiple threads (ie server side data portals) be trying to call these methods at the same time?

Thanks,

ajj3085 replied on Tuesday, October 02, 2007

That's right, the sample is not threadsafe. Just like many code samples don't show error handling in each example, Rocky's example doesn't show a threadsafe way of caching data.

jgk1701 replied on Tuesday, October 02, 2007

I have been experimenting with the Enterprise Library Caching Application Block and I am considering using this for caching. My code for the GetList and InvalidateCache methods would look something like this:

Public Shared Function GetList() As NameValueList
      Dim cm As CacheManager = CacheFactory.GetCacheManager
      Dim mList As NameValueList
      mList = DirectCast(cm.GetData("Key"), NameValueList)
        If mList Is Nothing Then
            mList = DataPortal.Fetch(Of NameValueList)(New Criteria)
            cm.Add("Key", mList)
       End If
       Return mList
End Function

Public Shared Sub InvalidateCache()
        Dim cm As CacheManager = CacheFactory.GetCacheManager
        cm.Remove("Key")
End Sub

Since the CacheManager is itself thread-safe (according to the Enterprise Library documentation), then there is no need for Synclock blocks in these methods, correct?

ajj3085 replied on Tuesday, October 02, 2007

I use the caching block as well, and it is my understanding the CacheManager is threadsafe. Your code is similar to mine (I use the Exists method before fetching or removing a cached item).

stefan replied on Tuesday, October 02, 2007

I cannot see the benefit of the code you posted above in a remote DataPortal scenario.
Using the CacheManager inside the shared/static GetList method usually affects only
clientside code, as I understand it. Of course we can call GetList() from within DataPortal_XYZ,
then you would manage a cache for all clients.

I don't know the Caching Application Block, so I might be wrong with my assumptions here.
For a perfect solution we would need to manage a CacheManager on the serverside (from within
DataPortal_Fetch) that would feed a local CacheManager. These two CacheManagers would have
to communicate with each other and somehow notify the clientside of any 'refresh' events...

Maybe Andy was indicating something like this with his Exists() hint...?

Just my two cents

Stefan

ajj3085 replied on Tuesday, October 02, 2007

The code will cache where ever it ends up being used. So if the client side uses it, it will cache there. If that same code (that is, the list is gotten through the code he posted) is also used in the DP_xzy methods (and RunLocal is not set), then it will cache on the server as well.

jgk1701 replied on Tuesday, October 02, 2007

For the most part, caching will occur on the client side. However, we have some objects with business rules which require look ups in read-only collections. Since we check business rules in DataPortal_Create and DataPortal_Fetch calls, these read-only collections will be loaded and cached on the server side.