Timeline for Pooling (Singleton) Objects Against Connection Pools
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 11, 2014 at 17:56 | comment | added | Robert Harvey | I think that running a profiler would provide a great deal of insight. | |
| Apr 11, 2014 at 11:01 | comment | added | kolossus | An oversight on my part, sorry about that; It's a multithreaded webservice that connects to a popular ECM. Currently, each request to that service creates a new DAO, which in turn tries to get a new connection. My thinking is that a single DAO (or pool of DAOs), given the fact that there's no mutable state anywhere along the chain of command. What do you think? | |
| Apr 10, 2014 at 20:40 | comment | added | Robert Harvey | @kolossus: This is just a counter-example. You didn't state in your question that this was an actual problem, nor did you provide any relevant detail with respect to your actual problem, so it's not unreasonable to the casual observer to conclude that you're talking about a hypothetical. All it takes is a single counter-example to refute a premise. | |
| Apr 10, 2014 at 20:32 | comment | added | kolossus | The way I read the linked material, these frameworks need to instantiate new context objects because by definition, they are context sensitive and consequently not reusable. The Linq resource also observes most other ORMs are stateless in their data connectivity and management object. The Linq-SQL pattern is not the norm. My example is far from hypothetical and there's no state being manipulated in the DAOs. In the same way a servlet container only ever creates a single instance of a servlet, it should be safe to reuse durable DAOs | |
| Apr 10, 2014 at 16:39 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 35 characters in body |
| Apr 10, 2014 at 16:19 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 228 characters in body |
| Apr 10, 2014 at 16:14 | history | answered | Robert Harvey | CC BY-SA 3.0 |