Skip to content
This repository has been archived by the owner on Jan 15, 2022. It is now read-only.

Adding a New Connection Pool Implementation

Owein Reese edited this page Aug 5, 2013 · 1 revision

One of the goals of this library was to make querying a database as fast as possible. Assuming all queries being properly tuned, the choice of connection pool had a considerable influence on the performance of a system under load. Thus, being able to swap different connection pool implementations became important to achieving the best overall system query speed.

To make it easy to test different connection pool implementations we needed to make our own code oblivious to the type of connection pool used. We also needed to handle database specific JDBC quirks. This being Scala (and not Java) we could achieve both goals without the use of some abstract factory proxy builder by pushing database specific functionality out into a type class while keeping connection specific logic wrapped up in an interface. Configuring, initializing, and instrumenting the connection pool was left as an implementation detail.

The QueryExecutor trait, providing all connection handling boilerplate, was built with stubs for closing the underlying connection pool and retrieving a JDBC Connection. To add support for, say a proprietary connection pool, we'd need only to do this:

class MyPropExecutor[DBType : Queryable](pool: PropPool) extends QueryExecutor[DBType]{
  def getConnection() = pool getConnection ()`

  def shutdown(){
    pool close ()
  }
}

object MyPropExecutor{
  def apply[DBType : Queryable](config: PropConfig, listeners: List[PropListener]): QueryExecutor[DBType] = {
    val pool = new PropPool(config)
    listeners foreach{ that =>
      pool addListener (that)
    }

    new MyPropExecutor[DBType](pool)
  }
}

And we'd be ready to go.

Clone this wiki locally