Is Singleton collection of Singletons possible??

[Daniel Billingsley]

Let's say I'm writing a business app and I want there to be only one
instance of the Customer object for each particular customer (representing a
database record) being edited.

Would it be possible to extend the Singleton pattern to handle this?

Assuming that my Customer class follows the Singleton pattern (particularly
Skeet's 4th version) I'm thinking if I add

private static SomeCollectionType customers;

and then change the factory to something like

public static GetCustomer(Guid customerID)
{
// check collection and return existing instance if found
// create new instance and return if not
}

I think I have my mind around the static and singleton concepts, but need to
make sure.

[Jon Skeet [C# MVP]]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

Let's say I'm writing a business app and I want there to be only one
instance of the Customer object for each particular customer (representing a
database record) being edited.

Would it be possible to extend the Singleton pattern to handle this?
Sort of - it would then be called the Factory pattern though :)
Assuming that my Customer class follows the Singleton pattern (particularly
Skeet's 4th version) I'm thinking if I add

private static SomeCollectionType customers;

and then change the factory to something like

public static GetCustomer(Guid customerID)
{
// check collection and return existing instance if found
// create new instance and return if not
}

I think I have my mind around the static and singleton concepts, but need to
make sure.

That would be fine - but for thread-safety you should basically have a
lock which is acquired *every* time GetCustomer is called. The fourth
singleton pattern isn't really much use to you here. The second pattern
is much closer to what you'd need to use.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel Billingsley]

Yeah but I would need the Factory to be a Singleton also or it defeats the
purpose. So I need a GetFactory() and then a GetCustomer() I guess.

As to the locking... help me sort this out in my head. The problem is two
threads could call GetCustomer() right? Since that isn't addressed by the
Singleton nature of the factory itself the locks are required.

So I could follow the 4th pattern for the factory itself and then use the
locks within GetCustomer(). Right? Not that the locking in the overall
pattern probably matters much at that point since I'm going to be locking
left and right in the other method anyway.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

Let's say I'm writing a business app and I want there to be only one
instance of the Customer object for each particular customer (representing a database record) being edited.

Would it be possible to extend the Singleton pattern to handle this?

Sort of - it would then be called the Factory pattern though :)

Assuming that my Customer class follows the Singleton pattern (particularly Skeet's 4th version) I'm thinking if I add

private static SomeCollectionType customers;

and then change the factory to something like

public static GetCustomer(Guid customerID)
{
// check collection and return existing instance if found
// create new instance and return if not
}

I think I have my mind around the static and singleton concepts, but need to make sure.

That would be fine - but for thread-safety you should basically have a
lock which is acquired *every* time GetCustomer is called. The fourth
singleton pattern isn't really much use to you here. The second pattern
is much closer to what you'd need to use.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

Yeah but I would need the Factory to be a Singleton also or it defeats the
purpose. So I need a GetFactory() and then a GetCustomer() I guess.
Well, the factory methods themselves needn't be part of an instance -
you don't need to have a separate class. Any reason not just to have a
static GetCustomer method?
As to the locking... help me sort this out in my head. The problem is two
threads could call GetCustomer() right?
Yes.
Since that isn't addressed by the
Singleton nature of the factory itself the locks are required.
Yes.
So I could follow the 4th pattern for the factory itself and then use the
locks within GetCustomer(). Right?
Yes, if you want to.
Not that the locking in the overall
pattern probably matters much at that point since I'm going to be locking
left and right in the other method anyway.

Right.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel Billingsley]

Yes I think I see your point. There's no need for there to ever be an
instance of the factory, as it's only purpose is to expose the static
GetCustomer() (in a Singleton way, of course).

I think I understand that while I could be assured there is only one static
collection, multiple threads calling GetCustomer() could be adding, objects
to it, which would most likely result in a mess. In other words, it's the
fact that my main Singleton object is a collection type, which is by
definition continually changing, that's the problem.

But it appears maybe Microsoft is ahead of me. This is from the Thread
Safety section for HybridDictionary:
"Public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Instance members are not guaranteed to be
thread-safe.

This implementation does not provide a synchronized (thread-safe) wrapper
for a HybridDictionary, but derived classes can create their own
synchronized versions of the HybridDictionary using the SyncRoot property.

Enumerating through a collection is intrinsically not a thread-safe
procedure. Even when a collection is synchronized, other threads could still
modify the collection, which causes the enumerator to throw an exception. To
guarantee thread safety during enumeration, you can either lock the
collection during the entire enumeration or catch the exceptions resulting
from changes made by other threads."

So if my singleton factory inherited from this HybridDictionary and followed
the fourth pattern, am I good, since 1) the factory itself would be a
singleton and 2) the public static collection would is thread-safe? (The
above caveat about enumeration taken into account, of course)

Or are they just locking internally anyway when they say it is thread-safe?

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

Yeah but I would need the Factory to be a Singleton also or it defeats the purpose. So I need a GetFactory() and then a GetCustomer() I guess.

Well, the factory methods themselves needn't be part of an instance -
you don't need to have a separate class. Any reason not just to have a
static GetCustomer method?

As to the locking... help me sort this out in my head. The problem is two threads could call GetCustomer() right?

Yes.

Since that isn't addressed by the
Singleton nature of the factory itself the locks are required.

Yes.

So I could follow the 4th pattern for the factory itself and then use the locks within GetCustomer(). Right?

Yes, if you want to.

Not that the locking in the overall
pattern probably matters much at that point since I'm going to be locking left and right in the other method anyway.

Right.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

Yes I think I see your point. There's no need for there to ever be an
instance of the factory, as it's only purpose is to expose the static
GetCustomer() (in a Singleton way, of course).
Well, in a thread-safe way, effectively.
I think I understand that while I could be assured there is only one static
collection, multiple threads calling GetCustomer() could be adding, objects
to it, which would most likely result in a mess. In other words, it's the
fact that my main Singleton object is a collection type, which is by
definition continually changing, that's the problem.

But it appears maybe Microsoft is ahead of me. This is from the Thread
Safety section for HybridDictionary:
"Public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Instance members are not guaranteed to be
thread-safe.
That's not particularly unique to HybridDictionary, of course. Most
classes in .NET are documented in that way...
So if my singleton factory inherited from this HybridDictionary and followed
the fourth pattern, am I good, since 1) the factory itself would be a
singleton and 2) the public static collection would is thread-safe? (The
above caveat about enumeration taken into account, of course)

Or are they just locking internally anyway when they say it is thread-safe?

I'm afraid I've lost the plot slightly at this point - but I'm sure
you'll have to do *some* locking yourself to get the behaviour you
want. A simple implementation of:

static Hashtable customers = new Hashtable();

static object padlock = new object();

static Customer GetCustomer (string id)
{
lock (padlock)
{
if (!customers.ContainsKey(id))
{
customers[id] = new Customer(id);
}
return (Customer) customers[id];
}
}

or something similar would be your best bet, I believe.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel Billingsley]

Sorry I lost you - it's my confusion rubbing off probably. :) I realize
that thread-safe claim would be true of most if not all of the collection
classes.

I don't think your example below assures there is only one collection, does
it? Or did you just intentionally leave out those details?

My thinking is that since MS says the collections are thread-safe I wouldn't
need to worry about the locking if GetCustomer(). In the case of the
Hashtable there's a synchronized wrapper, so this is what I'm thinking: (Of
course, if all the syncronized version is doing is using locks anyway than
it probably doesn't matter.)

public class CustomerCollection
{

static CustomerCollection customers = new CustomerCollection();
static CustomerCollection syncedCustomers =
Hashtable.Synchronized(customers);

static CustomerCollection()
{
}

private CustomerCollection()
{
}

public static Customer GetCustomer(string id)
{
if (!syncedCustomers.ContainsKey(id))
{
syncedCustomers[id] = new Customer(id);
}
return (Customer) syncedCustomers[id];
}

}
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

I'm afraid I've lost the plot slightly at this point - but I'm sure
you'll have to do *some* locking yourself to get the behaviour you
want. A simple implementation of:

static Hashtable customers = new Hashtable();

static object padlock = new object();

static Customer GetCustomer (string id)
{
lock (padlock)
{
if (!customers.ContainsKey(id))
{
customers[id] = new Customer(id);
}
return (Customer) customers[id];
}
}

or something similar would be your best bet, I believe.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

Sorry I lost you - it's my confusion rubbing off probably. :) I realize
that thread-safe claim would be true of most if not all of the collection
classes.

I don't think your example below assures there is only one collection, does
it? Or did you just intentionally leave out those details?
It ensures there's only one collection per AppDomain, certainly -
because it's only created when the static initializer runs.
My thinking is that since MS says the collections are thread-safe I wouldn't
need to worry about the locking if GetCustomer().

No, because you need to go through the process of:

1) Test if the customer is already there
2) If it is, return it
3) If not, create a new customer and put it in the collection

Another thread could come in and request the same ID between steps 1
and 3, meaning you end up with two customers for the same ID. Only each
individual step is thread-safe without locking - you need to
effectively do the whole operation atomically.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel Billingsley]

Well, of course. But for thread-safeness it's the 3rd step that is of
significance. That is to say, setting aside my specific application, the
problem is two threads attempting to add the same ID. I take "A Hashtable
can support one writer and multiple readers concurrently. To support
multiple writers, all operations must be done through this wrapper only." to
mean the synchronized Hashtable itself wouldn't allow that, and I'd end up
with an ArgumentException. How do you take it? (That's assuming I use the
Add method which maybe is not the code you posted before as I recall.)

Now, that's not to say that using locking isn't better than dealing with the
exceptions, if that's where you'll go next. I'll have to evaluate that. I
just want to make sure I'm understanding these concepts correctly first
though.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

My thinking is that since MS says the collections are thread-safe I wouldn't need to worry about the locking if GetCustomer().

No, because you need to go through the process of:

1) Test if the customer is already there
2) If it is, return it
3) If not, create a new customer and put it in the collection

Another thread could come in and request the same ID between steps 1
and 3, meaning you end up with two customers for the same ID. Only each
individual step is thread-safe without locking - you need to
effectively do the whole operation atomically.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

Well, of course. But for thread-safeness it's the 3rd step that is of
significance. That is to say, setting aside my specific application, the
problem is two threads attempting to add the same ID. I take "A Hashtable
can support one writer and multiple readers concurrently. To support
multiple writers, all operations must be done through this wrapper only." to
mean the synchronized Hashtable itself wouldn't allow that, and I'd end up
with an ArgumentException. How do you take it? (That's assuming I use the
Add method which maybe is not the code you posted before as I recall.)
No, you wouldn't end up with an ArgumentException - you'd end up with
each call locking all other calls out until it completed.
Now, that's not to say that using locking isn't better than dealing with the
exceptions, if that's where you'll go next. I'll have to evaluate that. I
just want to make sure I'm understanding these concepts correctly first
though.

The problem is that if two different threads can both reach step 2, you
create more than one object for the same ID, which is usually a bad
move.

With threading, I always take the "simple is best" approach: while
you're dealing with shared data, take out a lock. I think people
generally believe that locks are more expensive than they really are.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel Billingsley]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

No, you wouldn't end up with an ArgumentException - you'd end up with
each call locking all other calls out until it completed. <snip> The problem is that if two different threads can both reach step 2, you
create more than one object for the same ID, which is usually a bad
move.

Doesn't that contradict the doc, which explicitly says it supports multiple
writers in a thread-safe way? For the Add method it says the
ArgumentExeption means "An element with the same key already exists in the
Hashtable".

Up through Steps 3a, nothing has yet been created in the Hashtable. At that
point the two threads only "think" they're going to add the same key.
According to the information in the doc, one of them will ultimately fail in
step 3b.
With threading, I always take the "simple is best" approach: while
you're dealing with shared data, take out a lock. I think people
generally believe that locks are more expensive than they really are.

I agree, which is why I will evaluate whether just adding the locking would
be simpler than dealing with the exceptions. I expect it will. At this
point I'm trying to figure out why we're understanding Microsoft's
explanation of this so differently. Maybe at this point we're just using
different symantecs.

The doc also says "Even when a collection is synchronized, other threads
could still modify the collection, which causes the enumerator to throw an
exception. To guarantee thread safety during enumeration, you can either
lock the collection during the entire enumeration or catch the exceptions
resulting from changes made by other threads."

Although it doesn't say so, I would expect the same problem to exist with
Contains() and ContainsKey() which I would expect are just enumerating
through under the hood. That being the case, I've got to handle several
possible exceptions and I think just locking myself is indeed way simpler.

Here's the steps again, for reference
1) Test if the customer is already there
2) If it is, return it
3) If not, (a) create a new customer and (b) put it in the collection

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

No, you wouldn't end up with an ArgumentException - you'd end up with
each call locking all other calls out until it completed. <snip>

The problem is that if two different threads can both reach step 2, you
create more than one object for the same ID, which is usually a bad
move.

Doesn't that contradict the doc, which explicitly says it supports multiple
writers in a thread-safe way?

Not at all.
For the Add method it says the
ArgumentExeption means "An element with the same key already exists in the
Hashtable".
Assuming you use Add rather than the indexer, that just means you'll
get an ArgumentException - which isn't a good thing, is it?
Up through Steps 3a, nothing has yet been created in the Hashtable. At that
point the two threads only "think" they're going to add the same key.
According to the information in the doc, one of them will ultimately fail in
step 3b.
Yes, but that's hardly a good way of working, IMO.

With threading, I always take the "simple is best" approach: while
you're dealing with shared data, take out a lock. I think people
generally believe that locks are more expensive than they really are.

I agree, which is why I will evaluate whether just adding the locking would
be simpler than dealing with the exceptions. I expect it will. At this
point I'm trying to figure out why we're understanding Microsoft's
explanation of this so differently. Maybe at this point we're just using
different symantecs.

Locking would be simpler, more elegant, and almost certainly about as
performant.
The doc also says "Even when a collection is synchronized, other threads
could still modify the collection, which causes the enumerator to throw an
exception. To guarantee thread safety during enumeration, you can either
lock the collection during the entire enumeration or catch the exceptions
resulting from changes made by other threads."

Although it doesn't say so, I would expect the same problem to exist with
Contains() and ContainsKey() which I would expect are just enumerating
through under the hood.

No, because they can take out the internal synchronization lock for the
whole of their operation.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too