[hibernate-dev] Performance issues with HT_ tables?

[Marcel Stör]

On 14.12.10 11:11, Emmanuel Bernard wrote:
> I am not sure if that can help you but Steve has written some nice blog entries on the past on the subject
>
> http://in.relation.to/Bloggers/MultitableBulkOperations
> http://in.relation.to/Bloggers/BulkOperations

Thank you very much - both articles are very helpful, indeed!

I claim to understand what Steve wrote BUT I fail to see how these 
concepts are applicable in my case.

My inheritance hierarchy is as follows and the strategy is 'joined':

      Product
      /     \
   Offer  Article

So, in contrast to the example in the blog when I update a field of 
Article there's no need to update the Product table (it's not even a 
versioned update). For me the question remains: why does Hibernate 
resort to using something like 'update schema.article set flag=0 where 
(id) IN (select id from HT_article)'?

Be it as it may, besides taking veeery long to complete (>1h for 130.000 
articles) I noticed that the above statement causes the Java process to 
consume close to 100% CPU (i.e. 100% of a single core in multi-core 
environments). Similarly slow processing appears to affect all in-queries.
With the help of a profiler singled out 
o.h.e.query.ParameterParser#parse(String, Recognizer) as being the 
culprit. The method is awfully long but it essentially iterates over the 
query string char-by-char and does some processing. In doing so it calls 
o.h.u.StringHelper#firstIndexOfChar(String, String, int) which in turn 
calls String.indexOf(int, int). When you have an in-query with a few 
hundred or thousand values the actual query string might have a million 
characters depending on how long your parameter name is. So, 
String.indexOf(int, int) is called maaany times and String processing is 
slow.
Back to the original case...If Hibernate processes '...where (id) IN 
(select id from HT_article)' for 130.000 articles the query string might 
be a few million characters long...


> I'd say this content is still conceptually valid.
>
> On 14 déc. 2010, at 08:04, Marcel Stör wrote:
>
>> On 14.12.2010 03:02, Steve Ebersole wrote:
>>> Those tables are used as part of bulk update/delete HQL processing
>>
>> Thank you. That much I figured by now ;-)
>> However, this does not explain (for me) why
>> a) Why they are used at all in the situation I described - are they used
>> for all bulk update/delete HQL operations regardless of context/mapping
>> strategy?
>> b) Why the update in my situation runs for more than an hour. That's an
>> absolute disaster because all other transaction fail with lock timeout.
>>
>>> -- Sent from my Palm Pre
>>> On Dec 13, 2010 4:43 PM, Marcel Stör<marcel at frightanic.com> wrote:
>>> Sorry to ask for help on the dev list but it seems as if no regular user
>>> would ever have to deal with such low level issues.
>>>
>>> Since we're having serious performance problems (queries running more
>>> than an hour...) with HT_ tables I was looking for documentation that
>>> describes the when/why/how/etc. of temporary tables. It can't seem to
>>> find anything online or in the Hibernate books.
>>> All I find at http://www.google.com/search?q=hibernate%20%22HT_%22 are
>>> unanswered forum questions or dead JIRA entries.
>>>
>>> It'd be nice if one of the developers could point me into the right
>>> direction.
>>> -> Problem: https://forum.hibernate.org/viewtopic.php?f=1&t=1008637
>>
>>
>> --
>> Marcel Stör, http://www.frightanic.com
>> Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
>> O<  ascii ribbon campaign - stop html mail - www.asciiribbon.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


-- 
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org