[pjfanning]

Motivation

JdbcSessionUtil.tryWithResource takes the resource as a by-name parameter and evaluates it twice: once when calling func, and once again in the finally block.

def tryWithResource[T, C <: AutoCloseable](closeable: => C)(func: C => T): T = {
  try { func(closeable) }          // evaluates the by-name arg -> resource #1
  finally { try closeable.close()  // evaluates it AGAIN -> resource #2, closes #2

So the resource handed to func is never closed, and a second one is created just to be closed. Consequences:

• JdbcOffsetStore (lines 69, 80, 98, 114, 182, 200, 240, 281, 301) and SlickOffsetStore (lines 169, 176, 187, 193) leak a Statement/PreparedStatement on every call. When the JdbcSession is backed by a connection pool (connection returned to the pool rather than physically closed) these accumulate on the physical connection and can exhaust server-side cursors.
• tryWithResource(stmt.executeQuery()) in JdbcOffsetStore.readOffset and readManagementState executes the query a second time and leaks the first ResultSet.

Modification

Evaluate the by-name parameter once into a local val, and use that instance both for func and for close().

Result

The resource passed to func is the one that gets closed, no extra resource is created, and each query is executed once.

Tests

• New JdbcSessionUtilSpec asserts that exactly one resource is created and that the instance passed to the function is the one closed (also on function failure, and when close() throws SQLException). All 3 cases fail before the fix.
• sbt "jdbc/test" - 31 passed
• sbt "jdbc/mimaReportBinaryIssues" - success
• sbt checkCodeStyle - success
• sbt headerCreateAll - header added to the new spec

References

None - found during a resource-leak audit of the main sources