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<mar...@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@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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
