Available in versions: Dev (3.20) | Latest (3.19) | 3.18 | 3.17 | 3.16 | 3.15 | 3.14 | 3.13 | 3.12 | 3.11 | 3.10
Thread safety
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 Configuration and DSLContext among threads:
-
Configurationis mutable for historic reasons. Calls to variousConfiguration.set()methods must be avoided after initialisation, should aConfiguration(and by consequenceDSLContext) instance be shared among threads. If you wish to modify some elements of aConfigurationfor single use, use theConfiguration.derive()methods instead, which create a copy. -
Configurationcomponents, such asorg.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 wrappingConfigurationto be thread safe. If you are using aorg.jooq.impl.DataSourceConnectionProvider, for instance, you must make sure that yourjavax.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.
Feedback
Do you have any feedback about this page? We'd love to hear it!