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] <javascript:>> > >> 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.
