Follow-Up on discussions about jOOQ, Spring, and DataSources

[Lukas Eder]

Hello community,

Following up on the various discussions on this user group, I have now
added org.jooq.impl.Factory constructors taking a DataSource instead
of a Connection as an argument. This will be included in jOOQ 2.4.0:
https://sourceforge.net/apps/trac/jooq/ticket/1424

Internally, jOOQ now wraps all relevant JDBC objects, such that this
distinction (DataSource-mode, Connection-mode) can be abstracted to
all of jOOQ's internals, providing full backwards-compatibility.
Essentially, this was done:

- A DataSourceConnection (DSC) was created to wrap both DataSource and
Connection.
- If the wrapped Connection in DSC is null, the wrapped DataSource is
used to create one
- DSC.createStatement(), DSC.prepareStatement() and DSC.prepareCall()
methods return DataSourceStatement (DSS), DataSourcePreparedStatement
(DSPS), and DataSourcePreparedCall (DSPC)
- When DSS, DSPS, and DSPC are closed, they also close the underlying
DSC, if DSC contains a Connection created from a DataSource

The above design allows jOOQ to lazy-fetch a Connection from a
DataSource when needed AND to return (close) that Connection again, as
soon as any Statement is closed. Since jOOQ always closes Statements
after execution, this implementation will take care of correctly
handling a DataSource-driven Connection's lifecycle, while leaving
standalone Connections untouched.

This solution works in integration tests as well as in a
Spring-enabled test setup that Sergey provided me with, some months
ago (sample Spring configuration file is attached). It is available
from GitHub and as 2.4.0-SNAPSHOT here:
https://oss.sonatype.org/content/repositories/snapshots/org/jooq/

Early end-user tests are very welcome!

Cheers
Lukas

[j.sha...@gmail.com]

Nice... thank you... I can't wait to give it a try ...

[Lukas Eder]

>> - A DataSourceConnection (DSC) was created to wrap both DataSource and
>> Connection.
>

> Is it possible to supply my own implementation? This could be used to
> implement sessions and transaction brackets.

Yes, you should be able to supply your own implementation - which will
then be wrapped by jOOQ internally in a DataSourceConnection (DSC)

> In other projects, I had a ConnectionProvider for this which either wrapped
> a normal sql.Connection or a DataSource (where it would request and return
> the connection) or something else.

The best thing for this provider would be to implement DataSource and
be supplied as such to a jOOQ Factory

Cheers
Lukas

[digulla]

> In other projects, I had a ConnectionProvider for this which either wrapped
> a normal sql.Connection or a DataSource (where it would request and return
> the connection) or something else.

The best thing for this provider would be to implement DataSource and
be supplied as such to a jOOQ Factory

 I'd like to avoid this because of the unstable JDBC API: With every release, Sun adds some new methods which breaks code that extends JDBC interfaces :-(

So a new interface which just has two methods (borrowConnection() and returnConnection()) would move the unstable part into jOOQ hiding it from all your consumers.

Regards,

A. Digulla

[Lukas Eder]

Hi

>  I'd like to avoid this because of the unstable JDBC API: With every release, Sun adds some new methods which breaks code that extends JDBC interfaces :-(

With Java 8's defender methods / extension methods, these problems should be gone.

> So a new interface which just has two methods (borrowConnection() and returnConnection()) would move the unstable part into jOOQ hiding it from all your consumers.

This looks like the existing JDBC API to me. Re-implementing that might be a bad idea in terms of usability and compatibility.

Note, there is also another thread on this group dealing with the possibility of adding new types for JDBC abstraction with the purpose of simplifying exception handling.

Cheers
Lukas

[digulla]

Am Donnerstag, 14. Juni 2012 16:04:32 UTC+2 schrieb Lukas Eder:

Hi

>  I'd like to avoid this because of the unstable JDBC API: With every release, Sun adds some new methods which breaks code that extends JDBC interfaces :-(

With Java 8's defender methods / extension methods, these problems should be gone.

Cool :-) Only ... it will be 2018 until I can use that release ...

 

> So a new interface which just has two methods (borrowConnection() and returnConnection()) would move the unstable part into jOOQ hiding it from all your consumers.

This looks like the existing JDBC API to me. Re-implementing that might be a bad idea in terms of usability and compatibility.

Well, duh. I introduced the API in my code so that my mapper would work with more than a single version of Java (I was supporting 1.4, 5 and 6). But if you only plan to support Java 8, then that's of course not an issue for you.

Which means to me that I'll have to fork. I don't mind; I have lots of forks here. It's just frustrating to have to do it because of so few lines of code.

Regards,

A. Digulla

[Lukas Eder]

>> With Java 8's defender methods / extension methods, these problems should
>> be gone.
>
> Cool :-) Only ... it will be 2018 until I can use that release ...

Well, if 2018 is the next time you upgrade Java, then you have 6 years
without any worries about JDBC API evolution ;-)

>> This looks like the existing JDBC API to me. Re-implementing that might be
>> a bad idea in terms of usability and compatibility.
>
> Well, duh. I introduced the API in my code so that my mapper would work with
> more than a single version of Java (I was supporting 1.4, 5 and 6). But if
> you only plan to support Java 8, then that's of course not an issue for you.

jOOQ officially supports Java 6+. Any help making jOOQ runtime
backwards-compatible to 5 or even 1.4 is very welcome. However, I
might not be able to integration-test that.

> Which means to me that I'll have to fork. I don't mind; I have lots of forks
> here. It's just frustrating to have to do it because of so few lines of
> code.

I will re-read these threads again after my vacation to have a clearer
view about the various requirements. Remember, it's a few lines of
code for you, but a dozen of unit/integration tests for me and more
(potentially confusing) API for all the other users. So it's worth
thinking about these things twice (without a pina colada in my hand)
:-)

Stay tuned, and maybe send a patch for me to better understand what
you're trying to do with your API enhancement.

Cheers
Lukas

[Lukas Eder]

> I will re-read these threads again after my vacation to have a clearer
> view about the various requirements. Remember, it's a few lines of
> code for you, but a dozen of unit/integration tests for me and more

> (potentially confusing) API for all the other users. [...]

>
> Stay tuned, and maybe send a patch for me to better understand what
> you're trying to do with your API enhancement.

I've gone through this thread once more and I still fail to see what
your requirement would be. What would borrowConnection() and
returnConnection() do, according to you? Can you supply an
implementation draft?

Cheers
Lukas

[digulla]

I've gone through this thread once more and I still fail to see what
your requirement would be. What would borrowConnection() and
returnConnection() do, according to you? Can you supply an
implementation draft?

I have started with an implementation in my git branch. But basically, these methods do the same as you do in DataSourceConnection in getDelegate() and close().

Regards,

A. Digulla 

[Lukas Eder]

> I have started with an implementation in my git branch. But basically, these
> methods do the same as you do in DataSourceConnection in getDelegate() and
> close().

Nice, looking forward to seeing that