Thread safe singleton

Eric,

Have you considered something along these lines for your instance
property? (Assume Imports System.Web.Http Context, and _Instance is a
private member declaration of your class.)

Public Shared ReadOnly Property Instance() As RuleManager

'// Check to see if a session variable with the signature of
the
'// current singleton object exists.
If Current.Session ("RuleManage r") Is Nothing Then

'// Create a new instance of the object.
_Instance = New RuleManager

'// Store the object in the session, using the signature
declared
'// to retrieve it when requested.
Current.Session ("RuleManage r") = _Instance

Else

'// Retrieve the instance that currently exists in the
session.
_Instance = CType(Current.S ession("RuleMan ager"),
RuleManager)

End If

'// Return the singular session instance of the singleton,
whether
'// it was created or retrieved from the session.
Return _Instance

End Function

You are basically creating a Singleton for each individual user and
storing it in their Session. You don't have to worry about
cross-polluting the session now.

HTH,

Joseph

I have a VB.net dll project with a class that is a singleton. I've been
using this in winform apps without any problems. I would like to use this
same dll in a web form project but my singleton will cause problems because
some sessions may need different values in the singleton. I want to change
my singleton to store a private hashtable with different instances. I guess
this is more like a factory pattern now but that doesn't matter My main
concern is about thread safty. The code below is what I have so far. Is
this the correct way to protect access to the inner hashtable? Thanks for
the comments or suggestions.

Eric
Friend NotInheritable Class RuleManager
Private Shared mInnerList As new HashTable
Private Sub New()
'hide constructor
End Sub

Public Shared ReadOnly Property Instance(Option al ByVal UniqueKey As
String = "") As RuleManager
Get
If mInnerList.Cont ains(UniqueKey) Then
Return DirectCast(mInn erList(UniqueKe y), RuleManager)
End If

SyncLock mInnerList.Sync Root
If Not mInnerList.Cont ains(UniqueKey) Then
mInnerList(Uniq ueKey) = New RuleManager
End If
Return DirectCast(mInn erList(UniqueKe y), RuleManager)
End SyncLock

End Get
End Property
End class

Joseph,

Thanks for your suggestion. I would use that approach but the dll that I
currently have has the RuleManager scoped as Friend. This class is internal
to my dll. Basically all of my classes in the dll need to be able to work
with this RuleManager but the RuleManager may need to be different for each
session. Remember this dll needs to work with both web apps and winforms.

Thanks,

Eric
"Joseph Ferris" <jo***********@ gmail.com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

Eric,

Have you considered something along these lines for your instance
property? (Assume Imports System.Web.Http Context, and _Instance is a
private member declaration of your class.)

Public Shared ReadOnly Property Instance() As RuleManager

'// Check to see if a session variable with the signature of
the
'// current singleton object exists.
If Current.Session ("RuleManage r") Is Nothing Then

'// Create a new instance of the object.
_Instance = New RuleManager

'// Store the object in the session, using the signature
declared
'// to retrieve it when requested.
Current.Session ("RuleManage r") = _Instance

Else

'// Retrieve the instance that currently exists in the
session.
_Instance = CType(Current.S ession("RuleMan ager"),
RuleManager)

End If

'// Return the singular session instance of the singleton,
whether
'// it was created or retrieved from the session.
Return _Instance

End Function

You are basically creating a Singleton for each individual user and
storing it in their Session. You don't have to worry about
cross-polluting the session now.

HTH,

Joseph

If it's a singleton, won't all apps using the dll share the same hashtable
since there is only one instance of the class? Also, I thought you had to
use synclock for reads as well as writes for threadsafe classes. Sorry,
I'm
just learning!
--
Dennis in Houston
"Eric" wrote:

Joseph,

Thanks for your suggestion. I would use that approach but the dll
that I
currently have has the RuleManager scoped as Friend. This class is
internal
to my dll. Basically all of my classes in the dll need to be able to
work
with this RuleManager but the RuleManager may need to be different for
each
session. Remember this dll needs to work with both web apps and
winforms.

Thanks,

Eric
"Joseph Ferris" <jo***********@ gmail.com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

> Eric,
>
> Have you considered something along these lines for your instance
> property? (Assume Imports System.Web.Http Context, and _Instance is a
> private member declaration of your class.)
>
> Public Shared ReadOnly Property Instance() As RuleManager
>
> '// Check to see if a session variable with the signature of
> the
> '// current singleton object exists.
> If Current.Session ("RuleManage r") Is Nothing Then
>
> '// Create a new instance of the object.
> _Instance = New RuleManager
>
> '// Store the object in the session, using the signature
> declared
> '// to retrieve it when requested.
> Current.Session ("RuleManage r") = _Instance
>
> Else
>
> '// Retrieve the instance that currently exists in the
> session.
> _Instance = CType(Current.S ession("RuleMan ager"),
> RuleManager)
>
> End If
>
> '// Return the singular session instance of the singleton,
> whether
> '// it was created or retrieved from the session.
> Return _Instance
>
> End Function
>
> You are basically creating a Singleton for each individual user and
> storing it in their Session. You don't have to worry about
> cross-polluting the session now.
>
> HTH,
>
> Joseph
>

If it's a singleton, won't all apps using the dll share the same hashtable
since there is only one instance of the class? Also, I thought you had to
use synclock for reads as well as writes for threadsafe classes. Sorry, I'm
just learning!
--
Dennis in Houston

Dennis,

No, applications do not share objects or any other data from the dll.
Each application will execute the code in the dll independently of the
others so they will all be working with different instances of the
hashtable.

Yes, generally speaking you do have to use a lock for both reads and
writes for the code to be thread-safe. There are exceptions though.
In this particular case the code is thread-safe because 1) the
Hashtable can support one writer and multiple readers concurrently and
2) items are never removed from the Hashtable. The Hashtable is the
only collection in the .NET Framework that has partial thread-safety.

In general, I would avoid the practice of attempting to access data
structures without locks in this manner. Subtle problems might crop up
when the code is ran on different platforms or framework versions.

Brian

Dennis wrote:

If it's a singleton, won't all apps using the dll share the same
hashtable
since there is only one instance of the class? Also, I thought you had
to
use synclock for reads as well as writes for threadsafe classes. Sorry,
I'm
just learning!
--
Dennis in Houston

Brian,

I didn't really think about it yet until your message but I will have to
add a method to remove from the hashtable at some point. Do you have any
examples of a thread safe way to read and write to any colletcion? I may
want to change the hashtable implementation at some point.

Thanks,

Eric