maginatics / jdbclint Goto Github PK

Some implementations like MySQL buffer all results in-memory then send them to the JDBC drivers to make small ResultSet faster. Users can enable streaming mode to work around this for large ResultSet. Warn about large ResultSet so users can detect when they are using too much memory.

Some third-party library could create a Statement without closing it, e.g., org.h2.tools.RunScript.execute.

Long-lived transactions can cause excessive transaction log growth in databases.

JDBC lint could eagerly warn about unclosed by tracking them in the parent. For example, DataSource could collect all created Connections in a list, Connection.close would remove from this list, and DataSource.close could warn when the list contains any elements. We should also investigate using weak references/reference queues instead of finalization since the former is more reliable and would cooperate with this feature.

Unsure how to address this since it relies on finalizer behavior. Enable file logging then run System.gc until the expected log message appears?

Presently JDBC lint only exposes system properties to configure its checks. Instead it could expose its existing DataSource(Properties) and Connection(Properties) constructors which allow arbitrary configuration.

@diwakergupta does this address your use case?

Also update README.md with artifactId.

Some databases like MySQL 5.6 can avoid some overheads and perform better when issuing queries on read-only connections:

http://dev.mysql.com/doc/refman/5.6/en/innodb-performance.html#innodb-performance-ro-txn

JDBC lint could detect this situation and suggest setting Connection.setReadOnly.

These classes are similar to Blob and we can add support with a mechanism similar to Statement/PreparedStatement/CallableStatement.

Specifically, executeLargeBatch and executeLargeUpdate:

http://download.java.net/jdk8/docs/api/java/sql/Statement.html