-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: Serious performance problem related to dirty checking
PostPosted: Wed Nov 26, 2014 4:37 pm 
Newbie

Joined: Mon May 18, 2009 10:45 am
Posts: 9
Hi,

I have a serious performance (and memory) problem in production that is due to the fact that my persistence context is overwhelmed with thousands of template entities (e.g. FormTemplate, FieldTemplate, etc.) which are read-only in production but read-write in pre-production where a BA may update a template. For what it’s worth, the FormTemplate contains a OneToMany collection of FieldTemplates (which, like the entities, are 2nd Level cached). Because of the need to load FormTemplates and FieldTemplates (and other template entities) for most transactions, the dirty checking that occurs again and again is a major performance problem as my application is full of query-modify-query-modify scenarios. With that said, I’m looking for the best way to go about disabling the dirty-checking in production for these template entities. I am leaning towards having two separate configurations: production and pre-production. The production configuration would declare template entities to be immutable and the cache concurrency strategy for each template entity/collection to be READ_ONLY. The pre-production configuration would declare template entities to be mutable and the cache concurrency strategy for each template entity/collection to be NONSTRICT_READ_WRITE. Assuming that this is a viable approach, I believe I would have to move away from an annotation configuration to an xml configuration (to avoid having to modify source code).

JBoss AS 5.1
Hibernate 3.3.1

Please advise. Sincerely, Tom


Last edited by tmuldoon on Sat Nov 29, 2014 11:37 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Serious performance problem related to dirty checking
PostPosted: Wed Nov 26, 2014 5:14 pm 
Newbie

Joined: Mon May 18, 2009 10:45 am
Posts: 9
I should have stated that performance is not a major consideration in our pre-production environment. I should have also stated that I've been poring over Hibernate documentation, forums, etc. and while I've learned a lot about immutable entities, read-only queries, cache strategies, and more, I could really use an expert's advice.

Tom


Top
 Profile  
 
 Post subject: Re: Serious performance problem related to dirty checking
PostPosted: Sat Dec 06, 2014 11:06 am 
Newbie

Joined: Mon May 18, 2009 10:45 am
Posts: 9
An update...

I am currently leveraging an EntityListener to disable dirty checking...
Code:
public class ReadOnlyEntityListener {
    @PostLoad
    public void postLoad(Object entity) {
        Session session = HibernateUtil.getSession();
        if (session != null) {
            session.setReadOnly(entity, true);
        }
    }
}


This has a shortcoming in that a snapshot of the entity is constructed before postLoad runs.

With that said, I really want to declare the class immutable and use setReadOnly(entity, false) to re-enable dirty checking in the event that the entity does need to be changed. But, from what I've read in http://docs.jboss.org/hibernate/core/3.5/reference/en/html/readonly.html, it appears that I cannot do that...

Quote:
Hibernate treats a persistent entity of an immutable class the same way as a read-only persistent entity of a mutable class. The only exception is that Hibernate will not allow an entity of an immutable class to be changed so it is not read-only.


Please advise... Tom


Top
 Profile  
 
 Post subject: Re: Serious performance problem related to dirty checking
PostPosted: Tue Dec 09, 2014 9:19 am 
Newbie

Joined: Mon May 18, 2009 10:45 am
Posts: 9
Unfortunately, using @PostLoad to disable dirty checking (for the template objects) has proven to be more of a performance downgrade than otherwise. While some operations have gotten faster, more have gotten slower (some as much as 20-30%).

I really could use some advice.


Top
 Profile  
 
 Post subject: Re: Serious performance problem related to dirty checking
PostPosted: Tue Dec 09, 2014 9:20 am 
Newbie

Joined: Mon May 18, 2009 10:45 am
Posts: 9
And I'm seeing more garbage collection in a one-hour 10 user test (using Web Load).


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.