The PreparedStatement allocated here:
|
return JdbcPreparedStatementImpl(connection.prepareStatement(sql, generated), returnKeys) |
and the ResultSet allocated here:
are leaked because close is never called. Calling close is a requirement of JDBC and some drivers (e.g. pgjdbc-ng) rely on this resource cleanup to keep memory usage optimized.
I was using the smallest of tests while debugging an issue logged against the pgjdbc-ng driver so I cannot say this is the extent of the leaks; looking through the codebase it appears there may be quite a few more leaks similar to these.
Here was my simple test:
val db = Database.connect(
"jdbc:pgsql://localhost/test",
user = "test",
password = "test",
driver = "com.impossibl.postgres.jdbc.PGDriver"
)
transaction(db) {
for (i in 0 until 100000) {
TestTable
.selectAll()
.map { Test(it[id], it[name], [bin]) }
}
}
FYI, I ran with the pgjdbc-ng driver and -Xmx256m to help force GC which triggers the driver's internal leak housekeeper to report leaks.
The
PreparedStatementallocated here:Exposed/exposed-jdbc/src/main/kotlin/org/jetbrains/exposed/sql/statements/jdbc/JdbcConnectionImpl.kt
Line 58 in fa61743
and the
ResultSetallocated here:Exposed/exposed-core/src/main/kotlin/org/jetbrains/exposed/sql/Query.kt
Line 80 in fa61743
are leaked because
closeis never called. Callingcloseis a requirement of JDBC and some drivers (e.g.pgjdbc-ng) rely on this resource cleanup to keep memory usage optimized.I was using the smallest of tests while debugging an issue logged against the
pgjdbc-ngdriver so I cannot say this is the extent of the leaks; looking through the codebase it appears there may be quite a few more leaks similar to these.Here was my simple test:
FYI, I ran with the
pgjdbc-ngdriver and-Xmx256mto help force GC which triggers the driver's internal leak housekeeper to report leaks.