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 On Monday, March 11, 2013 4:34:51 PM UTC-4, Lukas Eder wrote: > > Hi Christopher, > > Thanks for asking. This might be a sore spot to be fixed before 3.0.0 GA. > > I've been digging in the code base to remember the reason(s) for this > contract. There are in fact three that I can remember: > > 1. The idea was inspired by the various discussions about pooled > javax.sql.DataSources, specifically in the context of a > javax.transaction.UserTransaction, which (sometimes) also guarantee to > return the same connection (c1 == c2) for subsequent calls to > DataSource.getConnection(). This is not specified in DataSource, but it is > implemented this way by some containers and pools. In that case, > Connection.close() doesn't have any effect before a tx.commit() or > rollback(). Likewise, DataSource.getConnection() only returns a fresh > connection (or the same, pooled one), once the surrounding JTA transaction > has finished. > 2. (Unfortunately), keeping this behaviour intact lead to easier > implementation of jOOQ's internals, when ConnectionProvider was introduced. > This might have been the driving force for this contract - thus > "unfortunately". > 3. Aaron Digulla's original contribution also worked this way. He might as > well just have wanted to maintain the contract that was discussed on this > user group, though. > > Now in fact, there is no reason why the current contract should be > maintained this way. It might be wise to loosen it. This would indeed allow > for decoupling ConnectionProviders from the lifecycles of a transaction / > Executor. jOOQ would guarantee to implementors that both p.acquire() and > p.release() be called exactly once per created statement. A case where the > number of created statements does not coincide with the number of executed > queries is when a Query is executed with keepStatement = true. Then, the > call to p.release() is postponed until the Query (and its underlying > Statement) is closed - possibly after many subsequent executions: > http://www.jooq.org/doc/3.0/manual/sql-execution/reusing-statements > > *Please, group, feel free to join this discussion. As long as we have > release candidates, these things can be changed easily.* > > Cheers > Lukas > > PS: acquire/release seemed to me the best matching verbs for the task. Any > alternatives, specifically for "acquire" are welcome, too :-) > > 2013/3/11 Christopher Deckers <[email protected] <javascript:>> > >> Hi Lukas, >> >> >>> There is this new ConnectionProvider type: >>> http://www.jooq.org/javadoc/latest/org/jooq/ConnectionProvider.html >>> >> >> I don't understand the Javadoc... >> acquire: >> "The general contract is that a ConnectionProvider is expected to always >> return the same connection, until this connection is returned by jOOQ >> through release(Connection)." >> release: >> "The general contract is that a ConnectionProvider must not generate a >> new connection in acquire(), before a previous connection is returned." >> >> It seems to say that: >> Connection c1 = p.acquire(); >> Connection c2 = p.acquire(); >> => c1 == c2; >> And in that case, do we have to release it twice too? >> >> so if a user sets a connection provider for things like the SQL Console >> (that is multi tabs, etc.) we have no way of acquiring/releasing new >> connections for different concurrent usages using a (shared) >> ConnectionProvider. We don't want the user to supply a >> ConnectionProviderFactory for that :) >> >> Instead, I would expect acquire() to always return a new unused >> connection (e.g.: creation or taken from a pool), and release() to notify >> that it is now unused (can be disposed or placed back into a pool). >> >> Or maybe there is something I am missing with regards to how JDBC >> connections work? Also consider that I expected one ConnectionProvider >> which multiple threads could call to acquire new connections (and I am not >> sure the same connection can be used by multiple threads). >> >> Cheers, >> -Christopher >> >> -- >> 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] <javascript:>. >> 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.
