Modifying context settings for single query

[ry...@monoicon.com]

Hi

I'm working on an export query that returns tens of millions of rows and in order to keep the memory usage under control I'm using the fetchStream() method to stream them into a zip file. I found that I also need to set the fetchSize on the settings object to prevent my application (Java EE on Wildfly with Postgres) pulling the entire result set into memory.

I have a single application scoped DSLContext that's being injected across the application and am trying to work out if it's going to be safe to modify the fetchSize on the settings object inside a single transaction. Following the processing I'm setting the fetchSize back to the default value. Other code within the application are using the standard fetch() and are expecting the entire result set to be returned.

I struggled a bit to work out if this is sensible/safe from the documentation or if I should have a separate DSLContext that I create specifically for these requests that need to change the fetchSize.

Thanks

Ryan

[Lukas Eder]

Hi Ryan,

You shouldn't modify the Settings object of your single application scoped DSLContext, because that's not a thread safe operation. Instead, access DSLContext.configuration() and call Configuration.derive() (or deriveSettings() for convenience) in order to create a locally scoped Configuration/DSLContext for that particular use-case.

I hope this helps,

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 jooq-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/486440d4-f706-4a22-80a7-e1e89d370f7cn%40googlegroups.com.

[Lukas Eder]

Of course, you can scope your fetchSize alteration to an individual ResultQuery by calling ResultQuery.fetchSize(), as well.

[ry...@monoicon.com]

Thanks for the very fast response, setting it on the ResultQuery gave the right result. I can see where I missed that in the documentation now too.