Hi Christopher, 2013/4/12 Christopher Deckers <[email protected]>: > Hi Lukas, > >> concrete use-case of a 3rd party tool that really relies on jOOQ >> providing it with a "dedicated" connection through the >> ConnectionProvider API. > > > Let's go back to the origins. In our application (the simple version being a > fat client deployed on all of our clients' users' computers with direct > database access), the contract of getting a connection through our > connection providing API is hard: you must release what you acquire and it > is reserved. All our integrated tools like our console can get connections > from that central place. At any time, even over a remote session with a > client when troubleshooting an issue, we can fire the console to log and/or > execute statements.
True, I remember you telling me this. It is a nice architecture for a client application. > This saved us on many occasions, both at development time as well as in > production. My goal was to try to ease this firing of the console in the > context of JOOQ too. > > Let's sum up: > 1. Is ConnectionProvider a generic way of acquiring connections: No. > 2. Does JOOQ provide a centralized/generic way of acquiring dedicated > connections: No. Correct. And: 3. Is any of this needed? No. ConnectionProvider is an SPI exposed by jOOQ to inject behaviour into jOOQ. It is not meant to be reused in a more general context. You may already have a very specific way of providing connections in your application, true. But then, just implement ConnectionProvider in addition to that, as an adapter to your mechanism. In other words, there are already excellent connection pooling libraries out there. Here's where jOOQ's mission stops. > Conclusion: it is unclear whether tools have to create their own mechanics > to get dedicated connections. Depending on the type of ConnectionProvider, > this may or may not be suitable, but using connections when it is not > suitable could result in awful corruptions. Yes it could. That's why the architect evaluating jOOQ is worth his money. :-) > I originally thought that with little API tweaks maybe users could create a > Configuration/ConnectionProvider per target and pass them to JOOQ DSL as > well as tools. Too bad! :) They still can. But jOOQ is just one target / actor in this environment. And it shouldn't be the "leading" actor. It is a consumer of the main architecture... Cheers Lukas -- 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/groups/opt_out.
