NotesOnPossibleNewZODBConnectionPool

Connection pooling strategy:

• Background

  ZODB 3 pools database connections:

  • Reusing connections makes effective use of the cache
  • A pool size limit prevents run-away connection growth, at the expense of sometimes causing applications to hang.

  If an app leaks connections, an application can hang. This is extremely painful and hard to debug.

  It would be better to not hang, but call for help.

• Goals
  • Reuse connections to make effective use of cache.
  • Don't hang app due to pool exaustion
  • Prevent unlimited pool growth
  • Prevent an excessive number of connections, except when absolutely necessary.

Possible design (sketch):

• Parameters
  • Pool size. This is the number of connections to keep around under normal conditions.
  • Maximum pool size. If the pool gets bigger than this, we need to ask hoomaans for help.
• The database keeps three connection lists:
  • allocated
  • opened
  • closed (used as a stack)
• When we want to open a connection.

  We check the closed list. If it is empty, we create a new connection and add it to both closed and allocated.

  If len(allocated) > max_pool_size, we log a panic. Otherwise, if len(allocated) > pool_size, we log a problem.

  We grab the last connection from the closed list, removing it from closed and adding it to opened.

• When we close a connection

  If len(closed) > len(opened) and len(allocated) > pool_size, then pop the first connection from closed and remove it from allocated. Log the action (info).

• Log messages (above) give the parameters and the lengths of opened and closed.