Hi Christopher, 2013/3/24 Christopher Deckers <[email protected]>: > Hi Lukas, > > I don't know if the wording is incorrect or if the contract is loose in a > way that may cause problems (and does not satisfy what I hoped I could do > with it). > >> 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. > > The "again and again" part is true provided that it was first released, is > that correct?
That is entirely up to the implementation. jOOQ will acquire() a connection every time it needs one. jOOQ will release() a connection every time it has finished with one. An example where this might be non-trivial for implementations: 1. Query Q1 is executed with fetchLazy() 2. Query Q2 is executed from the same executor with execute() 3. Query Q2 releases the connection 4. Query Q1's result is completely fetched, and releases the connection As you can see, there are two logical connections involved. Both are acquired from the same ConnectionProvider, but they are not released in the same order. The order is this: 1. acquire C1 2. acquire C2 3. release C2 4. release C1 Whether C1 and C2 need to be distinct physical connections, or whether they may be the same is up to the implementation (your implementation). This allows to externalise various connection pooling / transaction models, without jOOQ needing to know about them. > What I expect is acquire to reserve a connection. A new call to acquire > would reserve another connection. The only way to release a connection is to > release it. > Otherwise, if the same provider is used by 2 different threads, it is > unclear whether serving the same connection is a good thing. This means that you will have to keep an identity map in your ConnectionProvider, remembering which connection was already acquired by jOOQ. If you're using a connection pool, you will likely be able to just delegate the handling to that pool, as many pools implement precisely what you've stated above. >> 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()) > > I don't see why the connection provider javadoc mentions jOOQ execution > lifecycle. In my view, connection provider should be a generic utility, with > a Javadoc that reads: > > acquire(): Reserve and return a connection for dedicated use to the caller. > The caller must release this connection when finished. Note that this method > could be implemented to always return a new connection or take one from a > pool. > > release(Connection): Indicate that a connection previously obtained through > acquire() is not needed anymore and can be disposed or made available to > future calls to acquire(). I think that mentioning the jOOQ execution lifecycle will help users implement this interface correctly. Saying that jOOQ will call acquire() exactly once per execution will help predict things when running more complex transactions with 1-n Executor instances in jOOQ. Your correction will make the contract a bit vague. "Dedicated use" does not indicate *when* a connection is released by the "caller" (jOOQ). I think that explicitly or implicitly tying acquire() to the creation of an ExecuteContext and release() to ExecuteListener.end() will make the general jOOQ API more concise and predictable. Maybe, however, it is time to create a couple of drawings for the manual, explaining the various actors involved in jOOQ's various object lifecycles... The various implementation possibilities are already mentioned in the Javadoc here: https://github.com/jOOQ/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/ConnectionProvider.java > This way, other tools/APIs could make use of that Connection Provider. What tools / APIs did you have in mind? -- 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.
