Hi Ben, 2013/6/18 <[email protected]>
> You'd want to use CacheBuilder, which allowed us to pull away from the > limitations of and not abuse the Map interface. True, I had recently encountered this useful class in Guava, but forgot about it again. They're adding so many nice utilities so quickly, it's hard to keep up with all the good choices. > If you want to embed an LRU cache, which I don't think is the case, [...] > No, I don't think it's necessary. > many prefer its predecessor > (ConcurrentLinkedHashMap<http://concurrentlinkedhashmap.googlecode.com>) > as a lighter-weight dependency to shade. We > reworked<http://concurrentlinkedhashmap.googlecode.com/files/ConcurrentCachingAtGoogle.pdf>Guava's > implementations based on that project. > > As a user, I'd prefer a plugin scheme when possible to tease apart > complexities. It would be nice if jOOQ provided a good implementation or > two, which might require me to add a few more dependencies to the project, > to avoid repeated work. > The "plugin scheme" is much easier to implement than the cache. Also, it serves a much more general purpose (e.g. the custom mapping algorithms you originally suggested), so I'm positive that it will fit in 3.1 Cheers Lukas > On Monday, June 17, 2013 5:04:04 AM UTC-7, Lukas Eder wrote: > >> N.B: >> >> Guava's MapMaker might implement some more sophisticated maps for the >> task: >> http://stackoverflow.com/a/**264591/521799<http://stackoverflow.com/a/264591/521799> >> >> >> 2013/6/17 Lukas Eder <[email protected]> >> >>> >>> >>> >>> 2013/6/17 Ryan How <[email protected]> >>> >>> I don't see why it needs weak **references? I would just ** >>>> control the cache manually **within the application and if ** >>>> I need to get rid of all **references then call a clear()** method. >>>> >>> >>> Yes, at the client side, such a solution is good enough. You know your >>> own class loader. >>> >>> >>>> Of course if it was inbuilt **in Jooq and on by default it ** >>>> would be a different story. >>>> >>> >>> Precisely. That's what Joachim and I were referring to. >>> >>> >>>> Still, weak hash maps I don't **think would solve all issues. ** >>>> It might just prevent memory **leaks, which I don't think ** >>>> would be a major issue unless **you are using "into" for a ** >>>> growing number of classes... **which I guess might happen in ** >>>> an osgi environment or webapp **if you happen to be using ** >>>> Jooq from the shared **classpath. But in that case ** >>>> you're asking for trouble if **you wanna cache application ** >>>> classes in the shared **classloader classpath... or **something... >>>> >>> >>> The point here is that jOOQ shall not hold any strong references to >>> classes loaded by a ClassLoader C. Once a C is GC'ed, classes loaded by C >>> in jOOQ's cache should "disappear". That's where weak references are >>> useful. In fact, it probably makes sense to check if this rule isn't >>> violated already today. >>> >>> The weak references won't be GC'ed before the ClassLoader is unloaded >>> (to prevent memory leaks), as each ClassLoader contains a Vector of its >>> loaded classes as strong references. to prevent memory leaks, a fixed-sized >>> LRU Map would probably have to be used. >>> >>> this stuff does my head in... >>>> >>> >>> Same here. In case of doubt, I won't implement any such cache in jOOQ. >>> >>> >>>> >>>> Lukas Eder <lukas...@gmail.**com> wrote: >>>> >>>> >>>> >>>> >>>> >>>> 2013/6/17 Durchholz, Joachim <Joachim....@hennig-**fahrzeugteile.de> >>>> >>>> > [...] you could cache the results of the reflection >>>>> > (really it is the whole "parsing" algorithm, which >>>>> > uses reflection) globally for each class, so it >>>>> > re-uses the same generated "algorithm" whenever it >>>>> > sees the same class. >>>>> >>>>> Please make sure that the class objects don't get strongly >>>>> linked to from the cache. >>>>> This is surprisingly hard to get right actually. I once >>>>> tried to do something like that, and found that garbage >>>>> collection and weak references and WeakHashMaps somehow >>>>> do something subtly different than I had thought. In the >>>>> end, I punted and declared Introspector "barely sufficient >>>>> for the use case at hand". >>>>> >>>> >>>> It is indeed very hard to get right. Consider the WeakHashMap's Javadoc >>>> [1]: >>>> >>>> *Implementation note:* The value objects in a WeakHashMap are held by >>>> ordinary strong references. Thus care should be taken to ensure that value >>>> objects do not strongly refer to their own keys, either directly or >>>> indirectly, since that will prevent the keys from being discarded. >>>> >>>> It is hard to ensure that a Class<?> key is not indirectly referenced >>>> by a map value. The ReflectionMapper, for instance, holds a strong >>>> reference to the class and to members of that class. >>>> >>>> Since caching reflection is easy to get wrong, if Jooq is >>>>> ever going to use that, the hard-to-get-right aspects of >>>>> this should be solved by Jooq. Could be done by >>>>> - having (or linking to) a full in-depth description >>>>> how to do it right, >>>>> >>>> - offering a reflection cache data structure that does it >>>>> right, >>>>> - make Jooq's API accept the reflection info, but manage >>>>> the cache inside Jooq (and say in the Javadoc that the >>>>> code computing that reflection info must never retain >>>>> any references to that info). >>>> >>>> >>>> I will certainly think about these things a bit more. But I'm also >>>> thankful for contributions by someone who will get it right quicker than >>>> me... >>>> >>>> Cheers >>>> Lukas >>>> >>>> [1]: http://docs.oracle.com/**javase/7/docs/api/java/util/** >>>> WeakHashMap.html<http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html> >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "jOOQ User Group" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/** >>>> topic/jooq-user/mM19mjR-49g/**unsubscribe<https://groups.google.com/d/topic/jooq-user/mM19mjR-49g/unsubscribe> >>>> . >>>> To unsubscribe from this group and all its topics, send an email to >>>> jooq-user+...@**googlegroups.com. >>>> >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>>> >>>> >>>> -- >>>> 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. >>>> >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>>> >>>> >>> >>> >> -- > 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. > > > -- 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.
