MyBatis’ Alternative Transaction Management

On the jOOQ user group, we’re often being asked how to perform transaction management with jOOQ. And we have an easy answer ready: You don’t do that with jOOQ. You choose your favourite transaction management API, be it:

And the above list is far from being exhaustive. Transaction management is something very delicate, and it certainly should not be imposed by a library whose main purpose is not transaction management, because any such library / framework will provide you with at most a very leaky abstraction of its transaction model. In other words, if you just slightly want to deviate from “the standard” model (e.g. as imposed by Hibernate), you will suffer greatly, as soon as you want to run 2-3 queries outside of Hibernate – e.g. batch or reporting statements through jOOQ.

MyBatis’ Alternative Transaction Management

MyBatis is a SQL templating engine that provides a couple of features on top of alternative templating engines, such as Velocity, or StringTemplate. One of these features built on top of templating is precisely transaction management, as can be seen in the docs.

From what we can read in the docs, it looks as though MyBatis’ transaction managers can be overriden by Spring, for instance. However, it is not easy to see how this is done. In fact, given that MyBatis also solves Connection pooling (for which there are also very viable alternatives, such as c3p0 and DBCP), and mapping (which could be solved more easily with custom transformers, such as offered by Spring’s JdbcTemplate, or jOOQ’s RecordMapper).

As many frameworks, MyBatis tries to solve problems outside its core scope, which is SQL templating. While this may be a good thing as you only rely on a single dependency, it is also quite a lock-in, in case you have a more complex model. In the case of transaction management, we believe that this was not a good idea by MyBatis.

Thoughts from MyBatis users?

Detect JDBC API Misusage with JDBCLint

I’ve recently seen an advertisement for JDBCLint on the H2 User Group. JDBCLint is an Apache licensed JDBC proxy implementation that does some plausibility checks on the lifecycles of your JDBC objects. For instance, it
  • Checks if a ResultSet is closed twice
  • Checks if a ResultSet is not closed at all (in the finalizer)
  • Checks if a ResultSet yields unread columns
All of these checks can be disabled by specifying relevant properties on the proxy. And the best thing is that this proxy is so easy to integrate:

import com.maginatics.jdbclint.ConnectionProxy;
Connection connection =
connection = ConnectionProxy.newInstance(
    connection, new Properties());
// reports error and optionally throws exception

In addition to static code analysis tools like FindBugs or Alvor, this tool can help you find very subtle memory leaks in your large legacy application. Certainly a tool to have on your tool chain!

Alvor: Static SQL analysis in Strings passed to JDBC

I have recently discovered this nice Eclipse plugin here:

It evaluates String, StringBuilder, StringBuffer, CharSequence and many other types passed to JDBC method for subsequent execution. It doesn’t do a bad job at this, even if it is in beta mode. The rate of false positives that I have experienced is around 20% for regular SQL statements, and 100% for stored procedure calls (which seem not to be supported). Checks include:

  • Syntax correctness
  • Semantics correctness
  • Object availability

It does so by

  • Comparing SQL against its own internal SQL grammar
  • Checking SQL statements against an actual database (provided a JDBC driver, JDBC URL, user, password)

This is extremely powerful, as it can find common bugs resulting from bad SQL string concatenation, misspelled table / column names, type mismatches, etc. With findbugs’ capabilities of analysing control flows, this could be made even better to detect even remote corner-cases or SQL passed to methods for the concatenation of sub-clauses and sub-selects. An example screenshot is given on their website:

An Alvor Screenshot


Check out Alvor for yourself here:

Note, I have also posted a request to the FindBugs mailing list here:

Static SQL analysis of this sort would be a great addition to FindBugs. If you think so, too, please support my request on the FindBugs mailing list