Hi Darren,
2014/1/17 Darren Shepherd <[email protected]>
> Now that I think about it if the caching was done in the Configuration
> object, not stored in some global static, then that would seem like an
> acceptable solution. I can't image that in a dynamic classloader situation
> that you would be sharing the Configuration object such that it would cause
> a memory. Or at least in that situation you give the option to disable it.
>
Hmm, nice thinking. In principle, the Configuration object already holds a
reference to a DefaultRecordMapperProvider. It would probably be safe to
implement caching of { Class, DefaultRecordMapper } pairs in there and
enable it by default. DefaultRecordMapperProvider could then have a couple
of overridable properties that allow for influencing caching, e.g. to turn
it off, or to invalidate it. I have registered #2965 for this:
https://github.com/jOOQ/jOOQ/issues/2965
This can be implemented for jOOQ 3.3 and jOOQ 3.2.3
I guess that the last time this issue was discussed, there hadn't been such
an elegant SPI yet to inject record mapping behaviour.
> I found an IBM bug related to this, which is obviously for their J9 JVM,
> but it seems to indicate that java 7 introduced this slow down.
> http://www-01.ibm.com/support/docview.wss?uid=swg1IV53758
>
Interesting find!
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.
