2018-05-09 23:03 GMT+02:00 <[email protected]>: > Hi Jooqers, > > Given repository implementation something similar to below, I want to > clarify on how it behaves at run time. > > 1) Would this cause any concurrency issues with the query object that is > cached in to the queryMap. > *Note: *When we debugged the application we found out that bind() > operation is creating a new object, so it shouldn't be issue if multiple > threads are accessing the same queryMap. But would like to get a expert > advice also :) >
Nope that's not correct. As of jOOQ 3.x, Query is not a thread safe object, so you must not share it among threads. Also, HashMap isn't thread safe either, although you seem to have gotten "lucky" as the only writing to your HashMap occurs at repository initialisation time. Anyway, what's the point of doing this optimisation, which seems premature? Do you have any evidence of query construction being costly? From our benchmarks, it's the least costly part of a fully dynamic query execution. More expensive are: - The bind() API (due to an internal design flaw: https://github.com/jOOQ/jOOQ/issues/6616) - Rendering the SQL string every time. If this code is really very "hot", then the best optimisation is to generate the SQL string only once and then execute it with JDBC directly. For this, use Query.getSQL(), and Query.getBindValues(). - Actually executing the query (probably, this is usually the most expensive part) > 2) Please identify any other potential issues with the implementation? > Yes. Don't do it this way :) Revert to either ad-hoc construction of queries every time, directly in your getUserById() method, or if you really have good reasons to optimise this code, then cache the generated SQL string. 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/d/optout.
