Hi Garret 2014-12-10 23:19 GMT+01:00 Garret Wilson <[email protected]>:
> On 12/10/2014 2:12 PM, Lukas Eder wrote: > > > Just checking, have you already used a debugger to step through all the > jOOQ / ULTM code, etc? > > > Lukas, I confess I haven't. Things have been crazy with several projects > flying around, and today I'm a little extra lazy because it's my birthday. > Happy birthday! ;-) >From my experience, debugging is about 100x more efficient than guessing. The truth is only in the code, and it's Open Source (or "opened source" if you have a commercial subscription). So, I dare say that actual debugging should be the tool of choice for the lazy person (I'm incredibly lazy), because writing E-Mails and expressing abstract concepts in English after the fact is much more work ;-) Anyway, this is still a useful discussion also for future readers of this thread, and I learned a lot of things for a pending blog post that explains all these concepts very thoroughly... > >> Lukas, if I do *not* use ULTM, and if I manually turn off autocommit on >> a connection and then issue several jOOQ SQL commands, will jOOQ (via the >> DataSourceConnectionProvider) request a different connection for each >> command? >> > > Where would you turn off autocommit manually, if you use a DataSource? > Did you implement your own DataSource? > > > I'm reviewing code of a colleague, and it looks like this: > > connection = dslContext.configuration().connectionProvider().acquire(); > connection.setAutoCommit(false); > > Thereafter the code uses jOOQ to do stuff, but the code gets a DSLContext > by: > > DSL.using(connection) > > So my question was just to make sure I understood things. If the code > instead used DSL.using(jooqConfiguration), then it would break the entire > transaction, because jOOQ would request a new connection which wouldn't be > the one we're working on above. > Clearly, this code implements a "whatever works for me right now" strategy :-) Here's the point: ConnectionProvider is an SPI ( http://en.wikipedia.org/wiki/Service_provider_interface), not an "ordinary" API (http://en.wikipedia.org/wiki/Application_programming_interface). This means that you provide an implementation for jOOQ to call (SPI), instead of jOOQ providing an implementation for you to call (API). Things might still work, but they *feel* quirky, right? Intuition is usually a good guide. When something doesn't "feel" right, it probably isn't. So, the bottom line is: If you really want to call setAutoCommit() yourself, then don't pass the DataSource to jOOQ. Instead, do this: try (Connection connection = datasource.getConnection()) { connection.setAutoCommit(false); try { DSL.using(connection) ... // <<-- The only actually interesting code is here connection.commit(); } catch (Exception e) { try { connection.rollback(); } catch (Exception e2) { e.addSuppressed(e2); } throw e; } } And by now, you'll realise "Jeez, all that code EVERY TIME I want to run a transaction??" - and by that time you probably throw away this solution, and either implement your own ULTM, or use JavaEE, Spring, ULTM, or jOOQ transactions APIs instead, which all do exactly the above, more or less (probably more, e.g. JavaEE, Spring, and jOOQ transaction APIs also implement nested transactions with Savepoints). So, I know you said that your project is in a bit of a hurry and that you're lazy, etc :-) But getting things right up front is the best way to be truly lazy afterwards. Getting them to work as quickly as possible is the best way to spend the rest of the project fixing funny infrastructure issues all the time. > (I am beginning to think that the answer is, "this won't work, because >> jOOQ will indeed request a new connection for each command. >> > > No. jOOQ will request ANY Connection for each command. jOOQ doesn't care > how YOU produce that Connection. That's your business. > > > But I don't produce the connection. The ConnectionProvider produces the > connection, right? And in my example earlier, I indicated "I simply have a > jOOQ Configuration wrapping a data source (with no Spring and no pooling > and no anything else)", in which case jOOQ uses a > DataSourceConnectionProvider, correct? So jOOQ will request a connection > for each command, and that will wind up being a new connection from the > data source. That's how I understand it anyway. > Well, I still don't know how you created that DataSource and I thus don't know why you're assuming that it is creating a new Connection every time for jOOQ. It might be. But that's the DataSource's responsibility, not jOOQ's. So again, how **did** you implement that DataSource? (And why don't you use some connection pool?) -- 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/d/optout.
