Need to share one instance of an object across an ASP dot net application.

[newjazzharmony]

I want to share one instance of an object across an ASP dot net
application, and I'm trying to weigh the pros and cons of the following
two approaches:

a) Storing the object in ApplicationState
b) Storing the object in a static member variable (utilizing a
singleton design pattern)

Any recommendations on which method would be more suitable?
What happens in each of these cases if IIS decides to spawn a new app
domain?
Are there any other approaches that might be better than the ones I
mentioned?

The object in question is a dot net class wrapping a COM component.
The class creates an SSL session to a proprietary device that manages
encryption and decryption.

Thanks,
Jonathan

 

[sloan]

Check my blog:


http://spaces.msn.com/sholliday/ 10/24/2005 entry

You can easily convert this to a Application holder.

...

If you're not using a server farm, then my blog idea (converted to
application) could work.

If you're using a server farm, you may need to go to remoting, and have all
members of the web server farm talk to the 1 remoting server.



Actually, I just found the code for the Application one.
Read the blog for the explanation, and here is the code.






using System;
using System.Collections;
using System.Collections.Specialized;


namespace GranadaCoder.CachingFramework
{

public class WebApplicationDataStore : IDataStore
{
private static string WEB_APPLICATION_OBJECT_GUID =
"B777D4C2-1576-40C3-88F8-FA16E94DDC90"; //ensure uniqueness, other than
that doesn't serve any purpose
private static WebApplicationDataStore singletonInstance = null;
private Hashtable m_memoryStore = null;

private WebApplicationDataStore()
{
this.m_memoryStore = new Hashtable();
}

public static WebApplicationDataStore GetInstance()
{
if (null != System.Web.HttpContext.Current )
{
if (null != System.Web.HttpContext.Current.Application )
{
if (null !=
System.Web.HttpContext.Current.Application[WEB_APPLICATION_OBJECT_GUID] )
{
singletonInstance =
((WebApplicationDataStore)(System.Web.HttpContext.Current.Application.Get(WE
B_APPLICATION_OBJECT_GUID)));
}
}
}
if ((singletonInstance == null))
{
singletonInstance = new WebApplicationDataStore();

System.Web.HttpContext.Current.Application.Add(WEB_APPLICATION_OBJECT_GUID,
singletonInstance);
}
return singletonInstance;
}

public void Clear()
{
this.m_memoryStore.Clear();
}

public void Add(string key, object value)
{
if (this.m_memoryStore.Contains(key))
{
this.m_memoryStore.Remove(key);
}
this.m_memoryStore.Add(key, value);
}

public object Remove(string key)
{
object returnObject = null;
if (null != this.m_memoryStore )
{
if (this.m_memoryStore.Contains(key))
{
returnObject = this.m_memoryStore[key];
this.m_memoryStore.Remove(key);
}
}
return returnObject;
}

public object this[string key]
{
get
{
if (null != this.m_memoryStore[key] )
{
return this.m_memoryStore[key];
}
return null;
}
}

public int Size
{
get
{
if (null != this.m_memoryStore )
{
return this.m_memoryStore.Count;
}
return 0;
}
}
}


}

 

[sloan]

You need to remove the Interface reference IDataStore, fyi.

Its a simple interface, forcing the Add / Clear / Size and Remove methods.
(maybe the indexer too?)

But you don't necessarily need it. Just remove it to compile.

Check my blog:


http://spaces.msn.com/sholliday/ 10/24/2005 entry

You can easily convert this to a Application holder.

..

If you're not using a server farm, then my blog idea (converted to
application) could work.

If you're using a server farm, you may need to go to remoting, and have all
members of the web server farm talk to the 1 remoting server.



Actually, I just found the code for the Application one.
Read the blog for the explanation, and here is the code.






using System;
using System.Collections;
using System.Collections.Specialized;


namespace GranadaCoder.CachingFramework
{

public class WebApplicationDataStore : IDataStore
{
private static string WEB_APPLICATION_OBJECT_GUID =
"B777D4C2-1576-40C3-88F8-FA16E94DDC90"; //ensure uniqueness, other than
that doesn't serve any purpose
private static WebApplicationDataStore singletonInstance = null;
private Hashtable m_memoryStore = null;

private WebApplicationDataStore()
{
this.m_memoryStore = new Hashtable();
}

public static WebApplicationDataStore GetInstance()
{
if (null != System.Web.HttpContext.Current )
{
if (null != System.Web.HttpContext.Current.Application )
{
if (null !=
System.Web.HttpContext.Current.Application[WEB_APPLICATION_OBJECT_GUID] )
{
singletonInstance =
((WebApplicationDataStore)(System.Web.HttpContext.Current.Application.Get(WE
B_APPLICATION_OBJECT_GUID)));
}
}
}
if ((singletonInstance == null))
{
singletonInstance = new WebApplicationDataStore();

System.Web.HttpContext.Current.Application.Add(WEB_APPLICATION_OBJECT_GUID,
singletonInstance);
}
return singletonInstance;
}

public void Clear()
{
this.m_memoryStore.Clear();
}

public void Add(string key, object value)
{
if (this.m_memoryStore.Contains(key))
{
this.m_memoryStore.Remove(key);
}
this.m_memoryStore.Add(key, value);
}

public object Remove(string key)
{
object returnObject = null;
if (null != this.m_memoryStore )
{
if (this.m_memoryStore.Contains(key))
{
returnObject = this.m_memoryStore[key];
this.m_memoryStore.Remove(key);
}
}
return returnObject;
}

public object this[string key]
{
get
{
if (null != this.m_memoryStore[key] )
{
return this.m_memoryStore[key];
}
return null;
}
}

public int Size
{
get
{
if (null != this.m_memoryStore )
{
return this.m_memoryStore.Count;
}
return 0;
}
}
}


}

I want to share one instance of an object across an ASP dot net
application, and I'm trying to weigh the pros and cons of the following
two approaches:

a) Storing the object in ApplicationState
b) Storing the object in a static member variable (utilizing a
singleton design pattern)

Any recommendations on which method would be more suitable?
What happens in each of these cases if IIS decides to spawn a new app
domain?
Are there any other approaches that might be better than the ones I
mentioned?

The object in question is a dot net class wrapping a COM component.
The class creates an SSL session to a proprietary device that manages
encryption and decryption.

Thanks,
Jonathan

 

[newjazzharmony]

You can easily convert this to a Application holder.

Thanks for the reply.
I should have specified that I don't mind having one instance fof the
object for each web server in the farm.
I want to keep this solutionas simple as possible.

 

[bruce barker \(sqlwork.com\)]

while either method works, the singleton is a better pattern because of the
strong typing.

in either case a recycle is the same, you can end up with two instances of
the com object, on in the old domain and one in the new. if this is a
problem, then you will have to add unmanged code to handle it.

also, if its a STA com component (say a vb6 object)., then special
consideration are required to for asp.net to support STA objects and there
is a performance cost.


-- bruce (sqlwork.com)

 

[newjazzharmony]

while either method works, the singleton is a better pattern because of the

strong typing.

Thanks for the reply!