supercargo/guice-persist-jooq — pull request #1 by klimeryk (2014-12-09 19:58:43+00:00)
Title: The way of injecting a DSLContext into a DAO described in README.md is incorrect

Hi,
first of all, thanks for this module - it has helped immensly in setting up Guice with jOOQ.
However, I've stumbled upon an issue with the `@Transactional` annotation. Namely, it wasn't working ;) Or rather, the changes were commited to the database, even though there was a rollback... After more hours of debugging and scratching my head than I'm willing to admit, I've had a relevation - the `DSLContext` injected into the DAO and the one in `JdbcLocalTxnInterceptor` was just... not the same.

The source of the problem is that injecting `DSLContext` directly sets it to the value bound to the current thread (for example, the one doing the initialization, injecting dependencies, etc.). However, the same thread might not handle the request and a call to a `@Transactional` method/class. `@Transactional` looks up the `DSLContext` in a `ThreadLocal` and in the (very common) case I've described above, the `DSLContext` injected into the DAO and the one `JdbcLocalTxnInterceptor` will be modifing will just simply not be the same. So, `@Transactional` sets autoCommit to true, but the DAO uses a different DSLContext so it doesn't matter >_<.

This subtle difference is hinted in the [Guice's documentation about JPA](https://github.com/google/guice/wiki/JPA):

> Note that if you make MyService a @Singleton, then you should inject Provider instead.

I've included a pull request with proposed changes to README.md that describe a proper (in my opinion) way of injecting `DSLContext` - in most cases the service and/or dao are singletons, and even if not, it won't hurt and will avoid introducing a nasty bug in case someone makes them singletons in the future.