That's a good news. Thanks! jOOQ rulez! Maybe it would be a good idea to add this detailed information to JavaDoc or DSLContext introduction in manual.
Regards, Witold Szczerba On Nov 18, 2014 8:10 AM, "Lukas Eder" <[email protected]> wrote: > Hi Witold > > DSLContext is essentially just a wrapped Configuration with DSL methods on > it. So, let's focus on whether Configuration can be used by multiple > threads. > > Yes it can. It has been designed in a way to allow for it to be used by > multiple threads, although it is not inherently thread safe. As of jOOQ > 3.4, a Configuration is composed of three type composing its state and six > SPIs > > *Types composing its state:* > > - dialect() > - settings() > - data() > > *SPIs:* > > - connectionProvider() > - transactionProvider() > - recordMapperProvider() > - recordListenerProviders() > - executeListenerProviders() > - visitListenerProviders() > > In order to make Configuration usable by multiple threads, you must > obviously make sure that the Configuration state will not change after > initialisation (dialect, settings, data), and that all state provided by > your SPI implementations is thread safe. In particular, your > ConnectionProvider must ensure that it doesn't have shared state. This is > typically the case if you use jOOQ's DataSourceConnectionProvider backed by > a DataSource that can be used by multiple threads - e.g. a pooled data > source. > > In the case of your linked ULTMTest you delegate that responsibility to > H2's JdbcDataSource, which seems to be creating new Connections every time > you access DataSource.getConnection(). > > > In other words, it is safe - in your case - to always refer to the same > Configuration, and thus to the same DSLContext. We do the same in the jOOQ > / Spring / DBCP tutorial: > > http://www.jooq.org/doc/latest/manual/getting-started/tutorials/jooq-with-spring/ > > 2014-11-17 22:42 GMT+01:00 Witold Szczerba <[email protected]>: > >> Hi there, >> I was trying to find an answer to my question here, but still I am not >> sure if my case matches with what I have found. >> >> My question relates to the transaction management from recent thread. >> The DSLContext instance is created with DataSource. I am not 100% sure >> if the DSLContext (called "jooq" in my code) can be used >> simultaneously by many threads. >> >> The code is here: >> >> https://github.com/witoldsz/ultm/blob/master/src/test/java/ultm/core/ULTMTest.java >> >> I was not sure, so I have created a method jooq() which returns new >> instance on each call in that test. When I remove that method and >> replace it with one instance, created at boot time, the tests still >> pass, but I am not sure if they do just by accident. If I am reading >> correctly, the documentation says the DSLContext is as thread safe as >> Configuration instance is, but I am not sure if my configuration is, >> because it is created under the hood by jOOQ itself. >> >> >> The question is, does the "many_threads_scenario" test would work 100% >> fine with one jooq shared instance? Are there any constraints? >> > > Yes. Many customers use jOOQ this way. > > >> If the answer is yes, I could create one jooq instance in the >> application I use that library with jOOQ for and bind it to >> "singleton" context. Otherwise, I would have to inject the DSLContext >> provider everywhere, or make a proxy which would pick the right >> instance on each use. > > > This is usually only needed when: > > - You want to change dialect(), settings() or data() > - You want to use standalone Connections via jOOQ's > DefaultConnectionProvider, rather than DataSources > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
