Hi,
I'm wondering if there's an approved practice in a multi-threaded app. Should I have one DAO per thread or simply make one DAO a thread safe singleton.
+1
A:
This really depends a lot on the mechanism you're using for data access. If you have a very scalable data access, and lots of threads, using some form of thread static data access can be advantageous.
If you don't have scalable data access, your provider doesn't support multiple threads per process, or you just don't need the scalability at that point, using a singleton with appropriate synchronization is simpler and easier to implement.
For most business style applications, I personally think the singleton approach is easier to maintain, and probably better - if for no other reason than it's much, much easier to test effectively. Having multiple threads for data access is likely not required, as the data access is probably not going to be a bottleneck that effects usability (if you design correctly, and batch requests appropriately).
Reed Copsey
2010-01-04 18:04:50
My DAO's are actually connecting to two sources: SimpleDB and a PHP API via RPC. My guess is I should probably use DAO per thread with about 100 threads to avoid bottlenecking issues. Do you see any obvious reasons not to in this case?
bingle
2010-01-05 00:12:18
Probably better to make the DAO a singleton, and internally, just work asynchronously. It can then scale up using a ThreadPool as needed... This is especially true for the PHP API, as web requests work great asynchronously, and most web frameworks have good support for this...
Reed Copsey
2010-01-05 00:41:59
A:
Use the approach that best suits your application architecture, unless:
1) Your data access objects are expensive to create, in which case you should lean toward a thread-safe singleton.
2) Your objects maintain mutable state, as in the Active Record pattern. (Immutable DAO configuration state, like timeout thresholds, doesn't count.)
Jeff Sternal
2010-01-04 18:18:55