0

Given the following scenario

  • A canned enterprise application that maintains its own connection pool
  • A homegrown client application to the enterprise app. This app is built using Spring framework, with the DAO pattern

While I may have a simplistic view of this, I think the following line of thinking is sound:

  • Having a fixed pool of DAO objects, holding on to connection objects from the pool. Clearly, the pool should be capable of scaling up (or down depending on need) and the connection objects must outnumber the DAOs by a healthy margin. Good

  • Instantiating brand new DAOs for every request to access the enterprise app; each DAO will attempt to grab a connection from the pool and release it when it's done. Bad

Since these are service objects, there will be no (mutable) state held by the objects (reduced risk of concurrency issues)

I also think that with #1, there should be little to no resource contention, while in #2, there'll almost always be a DAO waiting to be serviced. Is my thinking correct and what could go wrong?

kolossus
  • 501
  • 3
  • 9
  • I wouldn't worry about any performance effects of DAO instantiation: http://programmers.stackexchange.com/q/149563/34183 – Mike Partridge Jun 09 '14 at 18:48
  • @MikePartridge - My concern is not the object instantiation per se; it's the resource contention that results that worries me. On instantiation, each object will attempt to grab a connection from the pool. Uncurtailed instantiation will result in quick exhaustion of the pool. Pre-instantiating will ensure controlled access to pooled resources – kolossus Jun 09 '14 at 20:38
  • For #1, how would you handle more requests than DAOs in the pool? – Mike Partridge Jun 10 '14 at 14:36
  • @MikePartridge - The same way any other pool handles it: queueing requests. Requests can wait within a specified timeout for a DAO to be available. The difference between that and actually pooling the resource in my case is that I don't have control over the timeout of the resource; hence why I'm trying to throttle it at the DAO level – kolossus Jun 10 '14 at 14:39
  • 1
    You don't have control over the timeout when using a database connection pool? What pool implementation are you using? – Mike Partridge Jun 10 '14 at 14:41
  • @MikePartridge - I mean it's outside of my reach from a domain perspective. It's not for a database, it's an ECM. Aside from the domain issue, I simply am not satisfied with the way the ECM responds to pool exhaustion - with catastrophic failure. – kolossus Jun 10 '14 at 15:09
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/15009/discussion-between-mike-partridge-and-kolossus). -- Never mind, Chrome doesn't like the SE chat because it uses mixed content. – Mike Partridge Jun 10 '14 at 15:27
  • @kolossus I hazard a guess that you are actually looking for some kind of degree-of-concurrency control, to prevent the inadvertent exhaustion of capacity-controlled resources? – rwong May 06 '15 at 01:43
  • @kolossus you may also want to ask at the ECM's forum to gather more information about how their connection pool works. – rwong May 06 '15 at 01:45

2 Answers2

1

Entity Framework and Linq to SQL both instantiate DAO's as needed.

DAO's in Entity Framework (they're called Data Contexts) are deliberately designed to be lightweight to instantiate, so you create a new one each time a data access is required. Sometimes folks try to cache these Data Contexts, but that is a design error, and it can cause concurrency problems (DataContext is not thread-safe). In general, you create one DataContext object for each Unit of Work.

Entity Framework is most commonly used with SQL Server; SQL Server maintains a pool of "recently-used connections" that can be reused, so that the process of opening a new connection is also as fast as possible.

Further Reading
Linq to SQL DataContext Lifetime Management
Building N-Tier Applications with Entity Framework ... for various approaches.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 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 – kolossus Apr 10 '14 at 20:32
  • @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. – Robert Harvey Apr 10 '14 at 20:40
  • 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? – kolossus Apr 11 '14 at 11:01
  • 1
    I think that running a profiler would provide a great deal of insight. – Robert Harvey Apr 11 '14 at 17:56
0

In addition to the practical insight from Robert Harvey's answer, I think it's important to keep in mind that big picture, both schemes are doing equivalent things. There will be some sort of queuing involved, regardless of which scheme you choose. The difference will be where that logic lives. If there is resource contention with providing connections to DAO objects, there would have been resource contention with allocating a DAO object to its consumer.

Dogs
  • 1,166
  • 7
  • 11