DSLContext and threads.

[Witold Szczerba]

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?

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.

Thanks,
Witold Szczerba

[Lukas Eder]

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 <pljos...@gmail.com>:

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 

[Witold Szczerba]

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

--
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 jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lukas Eder]

Hi Witold

2014-11-18 9:18 GMT+01:00 Witold Szczerba <pljos...@gmail.com>:

That's a good news. Thanks! jOOQ rulez!

Thanks :-)

Maybe it would be a good idea to add this detailed information to JavaDoc or DSLContext introduction in manual.

That's a very good idea. I'll do this right now:

- https://github.com/jOOQ/jOOQ/issues/3773

- https://github.com/jOOQ/jOOQ/issues/3774