haskellrdbmsconnection-poolinghdbc

Concurrent DB connection pool in Haskell


I am a Java programmer who learns Haskell.
I work on a small web-app that uses Happstack and talks to a database via HDBC.

I've written select and exec functions and I use them like this:

module Main where

import Control.Exception (throw)

import Database.HDBC
import Database.HDBC.Sqlite3 -- just for this example, I use MySQL in production

main = do
    exec "CREATE TABLE IF NOT EXISTS users (name VARCHAR(80) NOT NULL)" []

    exec "INSERT INTO users VALUES ('John')" []
    exec "INSERT INTO users VALUES ('Rick')" []

    rows <- select "SELECT name FROM users" []

    let toS x = (fromSql x)::String
    let names = map (toS . head) rows

    print names

Very simple as you see. There is query, params and result.
Connection creation and commit/rollback stuff is hidden inside select and exec.
This is good, I don't want to care about it in my "logic" code.

exec :: String -> [SqlValue] -> IO Integer
exec query params = withDb $ \c -> run c query params

select :: String -> [SqlValue] -> IO [[SqlValue]]
select query params = withDb $ \c -> quickQuery' c query params

withDb :: (Connection -> IO a) -> IO a
withDb f = do
    conn <- handleSqlError $ connectSqlite3 "users.db"
    catchSql
        (do r <- f conn
            commit conn
            disconnect conn
            return r)
        (\e@(SqlError _ _ m) -> do
            rollback conn
            disconnect conn
            throw e)

Bad points:

QUESTION 1: how to introduce a pool of connections with some defined (min, max) number of concurrent connections, so the connections will be reused between select/exec calls?

QUESTION 2: How to make "users.db" string configurable? (How to move it to client code?)

It should be a transparent feature: user code should not require explicit connection handling/release.


Solution

  • QUESTION 2: I've never used HDBC, but I'd probably write something like this.

    trySql :: Connection -> (Connection -> IO a) -> IO a
    trySql conn f = handleSql catcher $ do
        r <- f conn
        commit conn
        return r
      where catcher e = rollback conn >> throw e
    

    Open the Connection somewhere outside of the function, and don't disconnect it within the function.

    QUESTION 1: Hmm, a connection pool doesn't seem that hard to implement...

    import Control.Concurrent
    import Control.Exception
    
    data Pool a =
        Pool { poolMin :: Int, poolMax :: Int, poolUsed :: Int, poolFree :: [a] }
    
    newConnPool low high newConn delConn = do
        cs <- handleSqlError . sequence . replicate low newConn
        mPool <- newMVar $ Pool low high 0 cs
        return (mPool, newConn, delConn)
    
    delConnPool (mPool, newConn, delConn) = do
        pool <- takeMVar mPool
        if length (poolFree pool) /= poolUsed pool
          then putMVar mPool pool >> fail "pool in use"
          else mapM_ delConn $ poolFree pool
    
    takeConn (mPool, newConn, delConn) = modifyMVar mPool $ \pool ->
        case poolFree pool of
            conn:cs ->
                return (pool { poolUsed = poolUsed pool + 1, poolFree = cs }, conn)
            _ | poolUsed pool < poolMax pool -> do
                conn <- handleSqlError newConn
                return (pool { poolUsed = poolUsed pool + 1 }, conn)
            _ -> fail "pool is exhausted"
    
    putConn (mPool, newConn, delConn) conn = modifyMVar_ mPool $ \pool ->
        let used = poolUsed pool in
        if used > poolMin conn
          then handleSqlError (delConn conn) >> return (pool { poolUsed = used - 1 })
          else return $ pool { poolUsed = used - 1, poolFree = conn : poolFree pool }
    
    withConn connPool = bracket (takeConn connPool) (putConn conPool)
    

    You probably shouldn't take this verbatim as I haven't even compile-tested it (and fail there is pretty unfriendly), but the idea is to do something like

    connPool <- newConnPool 0 50 (connectSqlite3 "user.db") disconnect
    

    and pass connPool around as needed.