Pooling (Singleton) Objects Against Connection Pools

Posted by kolossus on Programmers See other posts from Programmers or by kolossus
Published on 2014-04-10T13:19:55Z Indexed on 2014/06/09 21:39 UTC
Read the original article Hit count: 183

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?

© Programmers or respective owner

Related posts about dependency-injection

Related posts about spring