Hi Lukas, What tools / APIs did you have in mind? >
I was thinking about the jOOQ console: the editor needs a different connection for every tab. Because of that level of isolation, I need different connections. I can't use a connection provider and would have to define a different connection provider where the contract is that acquire gives a dedicated connection. But ignore the console for a moment. My problem is that conceptually there are 2 needs: 1. A way to plug a connection factory (which reserves and releases connections) that various places of the library can use. 2. The way that factory is used to acquire a connection, use it once or many times, and release it, in various places of the library. So as a user I would expect to define my pooling logic: ConnectionProvider cp = new PoolConnectionProvider(); And use it in different places: a. Guarantee of a dedicated connection for 2 calls even if they use fetchLazy, immune to rollbacks, etc. (pseudo-code): Executor create1 = new Executor(cp, SQLDialect.MYSQL); R1 r1 = create1.fetchLazy(); Executor create2 = new Executor(cp, SQLDialect.MYSQL); R2 r2 = create2.xxx(); // here r2 is fully consumed, connection 1 is released. // here r1 is fully consumed, connection 2 is released. b. Connection re-use: Executor create = new Executor(cp, SQLDialect.MYSQL); R1 r1 = create.fetchLazy(); R2 r2 = create.xxx(); // here r2 is fully consumed. // here r1 is fully consumed, connection is released. For me, Executor is one place of the library that needs a connection. It can keep a counter internally for that special case of fetchLazy to only release when it reaches 0 so that the same connection is re-used (and maybe this counter is thread local so that 2 different threads are guaranteed to have their own connection if it is something you feel is beneficial). Using 2 different Executor instances with the same provider should guarantee using 2 different connections, though they can use the same connection pool by sharing the same pool-based connection provider. Going further, the connection provider set in the Configuration can be used by various places of the library without having to wonder whether there are risks of connection sharing. I am also thinking that the execute listener context should expose both the connection as well as the connection provider, so that users can execute requests in the context of the connection or acquire a new connection if there are unrelated requests they want to run, etc. Have I missed anything? Do you get a feel for the needs I am trying to express? What do you think? 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]. For more options, visit https://groups.google.com/groups/opt_out.
