Good news on the injection front. I ran with the Settings indicated and
for the first time got 100% of my jobs saved properly. I have a second
related client which has to store lists with 1k-10K entries. Any guess
as to the performance difference here with v. without PreparedStatement
in play? In this scenario, the jobs are much less frequent.
Thanks, as always
On 08/31/2017 02:49 PM, Lukas Eder wrote:
I'll have to weigh the injection risk.
jOOQ will inline the bind variables for you, escaping them
appropriately depending on their types - so there's no additional
injection risk from using StatementType.STATIC_STATEMENT.
Mainly I'm curious as to how this re-use is occurring and if
there's any corrective action in my general scheme. An explicit
closing of the db connection perhaps?
I remember having seen a similar (but not identical) issue in the
distant past when using PreparedStatement with ref cursor results. At
the time, it had to do with transactions and the JDBC autocommit flag.
This is just thinking out loud, it's not the same issue, but the JDBC
driver did have some issues with that...
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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.
