Thanks for everyone's feedback

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Looks like I've got a lot of reading to do :

As I understand the concept of Singleton objects, they can only be instantiated once. Then, all other calls to that object rely on that previously created instance. If you have 300 hundred users, and each of them are doing multiple things (i.e. pulling data, executing stored procedures, etc..), and each time some communication to the data layer takes place, it must filter through that ONE instance (the Singleton obj) because IT is set up to be your data access object, then how does this architecture benefit you? Would it not become a bottle-neck due to their being only the one instance of it
 
K. Miller said:
Looks like I've got a lot of reading to do :}

As I understand the concept of Singleton objects, they can only be instantiated once. Then, all other calls to that object rely on that previously created instance. If you have 300 hundred users, and each of them are doing multiple things (i.e. pulling data, executing stored procedures, etc..), and each time some communication to the data layer takes place, it must filter through that ONE instance (the Singleton obj) because IT is set up to be your data access object, then how does this architecture benefit you? Would it not become a bottle-neck due to their being only the one instance of it?
Click to expand...


No problem at all - problems arise only if you have blocking calls (have
a look at the "lock" keyword) in a multithreaded environment. As an
alternative to a Singleton Data Access Object, you can implement it as a
stateless class an expose it globally.

Example: I'm exposing my stateless (that's the magic word) Data Access
Objects through an initialization class. I recently set up a "best
practices" page providing the corresponding code snippet:
http://dao.evolvesoftware.ch/patterns.aspx

Cheers, Philipp
 
This is correct, but the time spent within the singleton should
really be minimal (it is supposed to delegate control to instances
of other classes behind the scenes, thus quickly being freed for
use by others).

In Gentle (my persistence framework) I've marked the access point
singleton as [ThreadStatic] so every thread has it's own copy. That
way I don't have to use locking and deal with thread issues (which
might be better, but certainly more complicated :). I probably have
too much functionality in the Broker (the singleton class) for it
not to become a bottleneck so your concern is valid if it were not
for the thread-singleton option ;)

Yours,
Morten
 
Back
Top