Since I've had no objections to Christopher's claims, I will change the jOOQ 3.0 contract of the ConnectionProvider. The new contract will include:
acquire(): Provide jOOQ with a Connection. The ConnectionProvider can freely choose, whether this connection is a new connection every time jOOQ calls this method, or if the same connection will be provided again and again. jOOQ will call this method exactly once per execution, when the ExecuteContext is initialised release(): Clean up a Connection that was previously provided to jOOQ. The ConnectionProvider can freely choose, whether cleaning up needs any action or not. jOOQ will call this method exactly once per execution, when the ExecuteContext is disposed (before ExecuteListener.end()) This will be implemented for jOOQ 3.0 through #2351 https://github.com/jOOQ/jOOQ/issues/2351 Existing ConnectionProvider implementations (on jOOQ 3.0-RC1 or RC2) will continue to work. Only jOOQ's internals are affected by this change. Cheers Lukas 2013/3/12 Peter Cooner <[email protected]>: > Hah, sorry, thats what I get for writing email late at night - clearly my > brain had disengaged. > > I intended to express my own confusion over ConnectionProvider. > > When I started working with JOOQ I had wanted to create a single Executor > instance and @Inject the object whenever I needed to execute queries. > Because Executor isn't thread safe I instead @Inject a JooqExecutorFactory > which returns my own InjectExecutor object which is basically bound to a > single Connection, and Executor instance (and transaction). I still feel > like that's probably pretty dumb - like I'm missing something - but I didn't > have time to unravel how ConnectionProvider could be useful and what sort of > state the Executor maintains. > > Just to be clear, what I do know is that JOOQ helps us write better queries > and transform those queries for table partitioning - a big win. > > > > > On Tuesday, March 12, 2013 3:55:51 AM UTC-4, Lukas Eder wrote: >> >> Hi Peter, >> >> So what would your setup mean for the jOOQ 3.0 ConnectionProvider >> contract? >> >> Cheers >> Lukas >> >> 2013/3/12 Peter Cooner <[email protected]> >> >>> I've not used javax.transaction.UserTransaction for my transaction - >>> instead because we make heavy use of Google's Guice library, I created an >>> annotation @Transaction turning any function with a Connection argument into >>> a transaction. Not sure if we'll stick to this, but so far it works well >>> enough, its very flexible. For pooling we're using Apache's DBCP which will >>> pool connections and statements. >>> >>> Pete >>> > -- > 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. > > -- 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.
