tag:blogger.com,1999:blog-3958623046725572438.post188631389298940317..comments2024-03-27T02:30:01.972-05:00Comments on capricious diatribes: Hibernate Wars: The Query Cache Strikes BackOldaghttp://www.blogger.com/profile/14242449133322470801noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-3958623046725572438.post-50129161544519009142022-03-03T08:04:19.039-06:002022-03-03T08:04:19.039-06:00Casino in San Diego, CA - Mapyro
Welcome to Casino...Casino in San Diego, CA - Mapyro<br />Welcome to Casino <a href="https://drmcd.com/%ea%b2%bd%ec%83%81%eb%82%a8%eb%8f%84%ec%b6%9c%ec%9e%a5%ec%95%88%eb%a7%88.html/" rel="nofollow">경상남도 출장샵</a> in San Diego, California. We have the biggest selection <a href="https://www.mapyro.com/%ec%a0%9c%ec%a3%bc%eb%8f%84%ec%b5%9c%ec%83%81%ec%9d%98-%ea%b4%80%eb%a6%ac%ec%b6%9c%ec%9e%a5%ec%83%b5.html/" rel="nofollow">제주도 출장마사지</a> of casino games and <a href="https://drmcd.com/%ea%b1%b0%ec%a0%9c%ec%b5%9c%ea%b3%a0%ec%9d%98%ec%b6%9c%ec%9e%a5%ec%83%b5%eb%b0%9b%ec%95%84%eb%b3%b4%ec%84%b8%ec%9a%94.html/" rel="nofollow">거제 출장샵</a> casino floor in the United States. Use the map to <a href="https://www.jtmhub.com/%ec%b2%9c%ec%95%88%ec%b5%9c%ea%b3%a0%ec%9d%98%ec%b6%9c%ec%9e%a5%eb%a7%88%ec%82%ac%ec%a7%80%eb%b0%9b%ec%95%84%eb%b3%b4%ec%84%b8%ec%9a%94.html/" rel="nofollow">천안 출장샵</a> find all <a href="https://www.jtmhub.com/%ea%b5%ac%eb%a6%ac%ec%b6%9c%ec%9e%a5%eb%a7%88%ec%82%ac%ec%a7%80%ec%9d%b8%ea%b8%b0-%ec%88%9c%ec%9c%84.html/" rel="nofollow">구리 출장마사지</a> you needyannicgaddhttps://www.blogger.com/profile/03469758055323261150noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-29868403685580231482021-07-24T04:15:05.920-05:002021-07-24T04:15:05.920-05:00such a great content...its very interesting to rea...such a great content...its very interesting to read...<br /><a href="https://www.cubikcadd.in/bentley-staad-pro-training-in-coimbatore.html" rel="nofollow"> Cadd centre fee structure in coimbatore</a> | <a href="https://www.cubikcadd.in/rhino-3d-cad-training-in-coimbatore.html" rel="nofollow"> Cadd course in coimbatore</a> | <a href="https://www.cubikcadd.in/autocad-training-in-coimbatore.html" rel="nofollow"> Autocad course in coimbatore</a> | <a href="https://www.cubikcadd.in/solidworks-training-course-in-coimbatore.html" rel="nofollow"> Solidworks course in coimbatore</a> | <a href="https://www.cubikcadd.in/autodesk-3ds-max-training-in-coimbatore.html" rel="nofollow"> 3dsmax course in coimbatore</a> | <a href="https://www.cubikcadd.in/creo-training-in-coimbatore.html" rel="nofollow"> Coreldraw course in coimbatore</a> | <a href="https://www.cubikcadd.in/autodesk-revit-training-in-coimbatore.html" rel="nofollow"> Electrical Cad course in coimbatore</a> | <a href="https://www.cubikcadd.in/autodesk-inventor-training-in-coimbatore.html" rel="nofollow"> Best cad training centre in coimbatore</a> | <a href="https://www.cubikcadd.in/ansys-training-in-coimbatore.html" rel="nofollow"> Ansys training in coimbatore</a> | <a href="https://www.cubikcadd.in/catia-training-in-coimbatore.html" rel="nofollow"> Catia training in coimbatore</a> | <a href="https://www.cubikcadd.in/civil-ansys-training-in-coimbatore.html" rel="nofollow"> Civilcad training in coimbatore</a> | <a href="https://www.cubikcadd.in/autocad-civil-3d-for-survey-training-in-coimbatore.html" rel="nofollow"> Cad software training course in coimbatore</a> | <a href="https://www.cubikcadd.in/" rel="nofollow"> Cad Project in Coimbatore</a><br />rajhttps://www.blogger.com/profile/03791553808484520532noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-36005431419208346392010-07-29T16:08:50.837-05:002010-07-29T16:08:50.837-05:00@ indian --
I've sorta stopped tracking the ...@ indian -- <br /><br />I've sorta stopped tracking the issue, as what we have is working for us. Perhaps check the hibernate jira issues or pester steve. :)Oldaghttps://www.blogger.com/profile/14242449133322470801noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-73276620774619119112010-04-21T05:17:55.959-05:002010-04-21T05:17:55.959-05:00Hi,
Was this query key issue fixed in hibernate 3...Hi,<br /><br />Was this query key issue fixed in hibernate 3.5.1? <br /><br />I am using the following maven dependencies:<br /><br /><br /> org.hibernate<br /> hibernate-entitymanager<br /> 3.5.1-Final<br /> <br /> <br /> <br /> org.hibernate<br /> hibernate-ehcache<br /> 3.5.1-Final<br /> <br /><br />Can they be used in production and live environments or should i wait for another release?indianhttps://www.blogger.com/profile/17715860723435688630noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-87155306235836406632009-05-11T21:56:00.000-05:002009-05-11T21:56:00.000-05:00then i propose "fix it" per issue HHH-3383;)
Agai...then i propose "fix it" per issue <A HREF="http://opensource.atlassian.com/projects/hibernate/browse/HHH-3383" REL="nofollow">HHH-3383</A>;)<br /><br />Again, Manuel replied in my other post that this might work, except that SessionImplementor is not currently available in the scope where QueryKey is constructed. Straightforward to fix, but probably touches a lot of code. Just a Simple Matter of Programming at that point. And, yay for test suites! (so one can be unafraid of refactoring)Oldaghttps://www.blogger.com/profile/14242449133322470801noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-35773113369369449732009-05-11T21:35:00.000-05:002009-05-11T21:35:00.000-05:00My brain said "QueryKey" and my fingers typed "Cac...My brain said "QueryKey" and my fingers typed "CacheKey". Never trust the fingers :)<br /><br />disassemble() is defined on the base Type contract : http://fisheye.jboss.org/browse/Hibernate/core/branches/Branch_3_2/src/org/hibernate/type/Type.java?r=16537#l313 meaning its available for all types. It (and its compliment assemble()) are the methods used to stored property values into the L2 cache and read them back. I was just saying it is probably just an oversight that those parameter values are currently not disassembled.Steve Ebersolehttps://www.blogger.com/profile/04954452918740670413noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-40020195298790995142009-05-11T16:51:00.000-05:002009-05-11T16:51:00.000-05:00@Steve,
I think HHH-2896 looks pretty interesting...@Steve,<br /><br />I think HHH-2896 looks pretty interesting. Definitely our biggest use of the query cache is for natural id lookups... and the existing issue comment(s) already point out that the issue should take those into consideration. For sure, something other than the criteria API would be more 'natural' to use for natural id centric loading, imho. If i think of anything to add, I'll be sure to do so.<br /><br />So, I'm not sure if you are referring to the L2 "CacheKey" or specifically the query cache's "QueryKey." I haven't found any problems with CacheKey, and it appears to already store the Serializable id identifier for the object in L2.<br /><br />QueryKey is another matter. It does have the Type[] for the positional parameters, and the named parameter map is just TypedValue(s), so the types are available there, too. Manuel posted a comment in my other blog entry (Dirty LIttle Secret) with some sample java code that appears to do nearly what we want (http://www.residencialaguardia.com/temp/QueryKey.java). However, it doesn't use that ManyToOne.disassemble path you reference. And I'd venture a guess your suggestion is more on target with my thinking. I just looked at the Type interface, and 'disassemble()' appears to do the right thing for each type appropriately. Good show.<br /><br />I'd like to try that out "when I can." But, as it stands, we have a solution in place that works for us, and getting some free time to play around a bit more might not be in the cards in the short term.<br /><br />As for the swap of the query string -- the goal there was to eliminate string duplication (and thus massively reduce heap use) as much as possible. The more I think about it, the more I come to realize it is the 'natural id query lookup optimization' that is biting us. If it were another query, be it a named HQL query or some static HQL (or sql) in our application -- then it would likely ALREADY be cached or singly-referenced JVM wide, and not be duplicated.<br /><br />However, since the sql for the criteria query is built up dynamically, each time -- the JVM cannot optimize that as a constant and you have the same sql text over and over and over in the QueryKey(s).<br /><br />I only did this to reduce memory overhead. I didn't consider, at all, any cpu-centric hashCode and comparison overhead. I purposely only "canonicalize" on the put (write) path, as to not introduce any extra churn or changes on the get (read) path. I didn't want to change anything there, like add a lock or do any QueryKey swapping, because we are way way more read-centric once the cache is populated. So, as long as we stay hashCode/equals compatible with both the modified put query key, and the query key that comes in on a read lookup, then nothing needs to change on the read path. That isn't to say perhaps some other benefit could not be found and utilized in this path, it just wasn't a profiled cpu hotspot for us.<br /><br />Alas, String.intern() reads like the perfect solution -- on paper. If all those sql strings were intern'd, we could resort to identity based map lookups. And, they would be guaranteed to use minimal storage. But, a bit of 'research' on the subject showed some myth and mystery around String.intern(), and my tech lead architect said "don't use it if you can avoid it." So, basically I ended up writing an intern-like map anyway, but that will use regular heap and not sit there in PermGen. On 2nd thought, I should probably use a weak hash map here so they go away if all the query keys get flushed. But, that is seriously not likely to happen in our case (at least, not for the sql test repetition case.Oldaghttps://www.blogger.com/profile/14242449133322470801noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-63056004866043929222009-05-11T09:40:00.000-05:002009-05-11T09:40:00.000-05:00Of course that should have read "there is already ...Of course that should have read "there is already a more correct (imho) solution to this <B>planned</B>..." ;)Steve Ebersolehttps://www.blogger.com/profile/04954452918740670413noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-87717830781203291292009-05-11T09:12:00.000-05:002009-05-11T09:12:00.000-05:00Hey Oldag,
Wanted to drop you a response to this ...Hey Oldag,<br /><br />Wanted to drop you a response to this post and the other Hibernate L2 cache one.<br /><br />First, in regards to the natural id look up cache, there is already a more correct (imho) solution to this : http://opensource.atlassian.com/projects/hibernate/browse/HHH-2896 Feel free to comment there if there are specific points you'd like to see addressed, or discuss it on the hibernate-dev mailing list or #hibernate-dev irc channel on freenode...<br /><br />WRT the parameter values used in the CacheKey, I have to believe it is just an oversight that the parameter value itself is used and not its "disassembled" state. The key already has access to the Type objects needed to disassemble them. Would you be willing to give that a try and see how it works out? The disassembled state of an entity is its id -> http://fisheye.jboss.org/browse/Hibernate/core/branches/Branch_3_2/src/org/hibernate/type/ManyToOneType.java?r=16097#l148<br /><br />WRT the query string I actually don't get exactly what you are doing. You swap one string for another string where both have the same content. Not really seeing the point. Reusing the same string instance each time would alleviate the calculation of the hashCode (which String caches on a delayed basis) but you use the initial string in the HashMap lookup, so its hasCode would get calculated as well; so no savings there (and that would just be a time saving anyway). Also, this code is functional similar to String.intern(). So I am confused with this one, could you expand?Steve Ebersolehttps://www.blogger.com/profile/04954452918740670413noreply@blogger.comtag:blogger.com,1999:blog-3958623046725572438.post-66011800419486995052009-05-06T03:50:00.000-05:002009-05-06T03:50:00.000-05:00Good postand nice sample. Possibly you also want t...Good postand nice sample. Possibly you also want to check out my Hibernate posts and tell me what you think.<br /><br />- Alois<br /><br />http://blog.dynatrace.comAlois Reitbauerhttps://www.blogger.com/profile/00403191732214679528noreply@blogger.com