Hi Christopher, I'm sorry, this mail was lying around unanswered for a while.
2013/3/24 Christopher Deckers <[email protected]>: > 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. I don't agree with these thoughts. The Executor should have no impact whatsoever on the behaviour of the connection provider. The whole point of introducing a connection provider is to externalise *all* responsibility of when connections are created and when pre-existing ones are returned to a single entity. In both cases a) and b), it is client code who knows the "ultimate truth" about transactional contexts. It should be client code who is in control of telling jOOQ how to behave. So if you want a) and b) to behave differently, then you will need to implement different connection providers. > 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. I can see how this is relevant to the jOOQ Console. Here's how to achieve the above: // Get a hold of the JDBC Connection being used in the // current execution context. This may lazy-initialise the // Connection, acquiring it from the ConnectionProvider ExecuteContext.connection(); // Get a hold of the ConnectionProvider from the // surrounding Configuration: ExecuteContext.configuration().getConnectionProvider(); > Have I missed anything? Do you get a feel for the needs I am trying to > express? What do you think? Maybe we should start discussing about concrete use cases of the jOOQ Console, instead? As soon as I've heard "ThreadLocal", I thought that this discussion isn't about general API and contracts any longer... Note, it is good to challenge an API / contract from the point of view of a very concrete use-case. So, feel free to shed some light on your use-case's details :-) Cheers Lukas -- 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.
