Question

I was previously using the application object to cache data that never changes. I am rewriting the project and have found out the aplication object is a no-no and is just there for legacy support from clasic ASP.

I know I can also use the cache – but I don’t want to as I use that for data that needs to be invalidated.

I am therefore looking at static variables for static data (makes sense).

My question is, rather than specifying static variables in each class, I was thinking of using a hashtable to store all the data and wrapping it into its own class – like a factory.

Something like this:

''' <summary>
''' Methods and properties related to the access and management of the local static memory cache.
''' Fastest type of cache but not available across applications, web farm or web garden environments.
''' Use this cache when data is static or can be stale across application instances.
''' </summary>
''' <remarks></remarks>
Public Class LocalStaticCache

    'Internal data holder:
    Private Shared _objCache As Hashtable = Hashtable.Synchronized(New Hashtable)

    Private Sub New()
    End Sub

    ''' <summary>
    ''' Gets or sets an object in cache. Returns Nothing if the object does not exist.
    ''' </summary>
    ''' <param name="key">The name of the object.</param>
    ''' <returns></returns>
    ''' <remarks></remarks>
    Public Shared Property Item(key As String) As Object
        Get
            If String.IsNullOrEmpty(key) Then Return Nothing
            Return _objCache(key)
        End Get
        Private Set(value As Object)
            _objCache(key) = value
        End Set
    End Property

    ''' <summary>
    ''' Insert an object into the cache.
    ''' </summary>
    ''' <param name="key">The unique object key.</param>
    ''' <param name="value">The object to store in the cache.</param>
    ''' <remarks></remarks>
    Public Shared Sub Insert(key As String,
                             value As Object)
        If Not String.IsNullOrWhiteSpace(key) Then

            If _objCache.ContainsKey(key) Then
                'If the key already exists in the Cache it will overwrite only if the objects differ:
                Interlocked.CompareExchange(Item(key), value, value)
                Return
            End If

            'store the item to the cache:
            Item(key) = value
        End If
    End Sub

    ''' <summary>
    ''' Remove an object from the cache.
    ''' </summary>
    ''' <param name="key">The key of the object to remove.</param>
    ''' <remarks></remarks>
    Public Shared Sub Remove(key As String)
        If _objCache.ContainsKey(key) Then
            _objCache.Remove(key)
        End If
    End Sub

End Class

Do you think storing all static data into a hashtable is this a good idea for performance,
or would it be better for each class to have its own static data holders inside their class?

Is this thread safe? Note: I am implementing Hashtable.Synchronized and Interlocked.CompareExchange to prevent race conditions – but what about locking and contention?

Note, the data is never changed once it has been set the first time round (the items in the hashtable never need updating).

I have datasets and large chunks of record sets as memory streams to store.

Any thoughts or pointers?

thanks.

Answer 1

Instead of writing your own static Hashtable and reimplementing Application you better use the Application Storage directly.

Another option is to use the ASP.NET Cache object, because the data can be deleted when not used.

Adding and removing data from a Hashtable is thread safe (write from one thread only). If you initialize the data on Application_Start you don’t have to use any locks because the data does not change.

If the data never should be deleted I would store the data in different classes depending on the context of the data. Use several singleton classes with lazy initialisation for this purpose.

For new applications I would not use datasets (or recordsets?) any longer. You better use the entity framework where you can basically generate your data access layer.

Hope this helps.