Available in versions: Dev (3.19) | Latest (3.18) | 3.17 | 3.16 | 3.15 | 3.14 | 3.13 | 3.12 | 3.11 | 3.10 | 3.9
This documentation is for the unreleased development version of jOOQ. Click on the above version links to get this documentation for a supported version of jOOQ.
Applies to ✅ Open Source Edition ✅ Express Edition ✅ Professional Edition ✅ Enterprise Edition
org.jooq.Configuration, and by consequence
org.jooq.DSLContext, make no thread safety guarantees, but by carefully observing a few rules, they can be shared in a thread safe way. We encourage sharing
Configuration instances, because they contain caches for work not worth repeating, such as reflection field and method lookups for
org.jooq.impl.DefaultRecordMapper. If you're using Spring or CDI for dependency injection, you will want to be able to inject a
DSLContext instance everywhere you use it.
The following needs to be considered when attempting to share
DSLContext among threads:
Configurationis mutable for historic reasons. Calls to various
Configuration.set()methods must be avoided after initialisation, should a
Configuration(and by consequence
DSLContext) instance be shared among threads. If you wish to modify some elements of a
Configurationfor single use, use the
Configuration.derive()methods instead, which create a copy.
Configurationcomponents, such as
org.jooq.conf.Settingsare mutable as well. The same rules for modification apply here.
Configurationallows for supplying user-defined SPI implementations (see above for examples). All of these must be thread safe as well, for their wrapping
Configurationto be thread safe. If you are using a
org.jooq.impl.DataSourceConnectionProvider, for instance, you must make sure that your
javax.sql.DataSourceis thread safe as well. This is usually the case when you use a third party connection pool.
As can be seen above,
Configuration was designed to work in a thread safe way, despite it not making any such guarantee.
Do you have any feedback about this page? We'd love to hear it!