2013/9/9 Eric Schwarzenbach <[email protected]>
> I'm not sure I entirely get it. How exactly does the connection /
> threadlocal mechanism in use case 2 operate? Would it try to get the
> ThreadLocal Configuration, and if it didn't exist, use / create a
> Configuration (with connection) from the using() arguments, and if it did
> exist, just ignore the using() arguments and use the ThreadLocal
> Configuration instead?
>
More or less. I may have confused a couple of wordings, or the order of
preference. Here's the implementation of DSLContext.fetch(ResultQuery) that
I had in mind
@Override
public <R extends Record> Result<R> fetch(ResultQuery<R> query) {
try {
pushToThreadLocal(configuration);
return query.fetch();
}
finally {
popFromThreadLocal();
}
}
As opposed to the implementation of ResultQuery.fetch():
@Override
public final Result<R> fetch() {
Configuration c = peekFromThreadLocal();
if (c == null)
c = configuration();
// [...]
}
> And does this mean if the query object passed into the fetch() (in your
> example "select().from(...)") is now thread safe and a single copy can be
> used in multiple threads?
>
With respect to Configuration? Yes. With respect to changing bind values?
No.
Beware, that there is a more state in a Query object, other than just the
Configuration. For instance, a Query may keep a reference to an open
PreparedStatement after execution as documented here:
http://www.jooq.org/doc/3.1/manual/sql-execution/reusing-statements
... which makes me think that maybe, I should abandon this ThreadLocal idea
for now and see if this can be fixed more generally. Christopher's idea at
the time can be seen here:
https://groups.google.com/d/msg/jooq-user/Y_tfF_eaxKM/U6EZvtkPWloJ
Essentially, it would consist of:
using(configuration).bind(Query).bind(... bindings ...).fetch();
In his model, there would be two APIs:
- Query (the static, immutable, thread-safe AST of your query)
- BoundQuery (the mutable, short-lived executable query)
This model still leaves open questions with respect to inline bind values,
but it would probably be quite clean...
--
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.
