-----Original Message----- From: Gavin King [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 2:44 PM To: Steve Ebersole Cc: Max Andersen; Hibernate development Subject: Re: [Hibernate] someone looking at flushing performance...
Steve Ebersole wrote: >The read-only stuff would not fix this issue, as I understand it. From >what I think that user is asking for, he still probably wants to the >flushes against the "main entity" to be honored and just wants the >reference data excluded from the flush checking. > >I think he's suggestion makes good sense, where the check to see whether >an entity is mutable comes before checking it's attributes for >dirtiness. At least in the current implementation, that makes a lot of >sense to me. > I recently changed how this works a little bit and the current implementation is basically as-good-as-can-be in HB3. I think it does, in fact, address part of the issue. The other half of the issue is that in order to determine if a flush is really necessary, we dirty check the entire session, rather than just the entities which are touched by the query. This is a bit hard to fix, and I'm very far from convinced it would be worth the effort. Remember, in the case that a flush *is* needed, we would need to then somehow "finish" the dirty check. Actually, the above statement of the problem is waay too simplistic, since it ignores the importance of processing cascades, etc. <steve> Sure, but all I'm talking about is the processing inside SessionImpl.flushEntity(). If an entity is not mutable, there is a bunch of stuff there that is not necessary between wrapping collections and performing the FlushVisitor processing. The only question would be the semantics of a class marked to be versioned in addition to being non-mutable, supposedly I guess to increment the version on changes to its collections; but even here in the current code the owning entity would not be physically updated if this were the case. </steve> > >However, right before the holidays I started work on breaking down the >SessionImpl into even more basic components. Another thought here might >be to further split what is now called PersistentContext. The idea >would be to split the concepts of 1) tracking an entity's state from 2) >defining the "scope of object identity". This would actually help later >on with some potential issue I have been thinking about regarding a good >read-only session implementation. Then we could continue to track these >objects within the scope of object identity but not in the session cache >(aka, this is analogous to TopLink's distinction between Session and >UnitOfWork). > Refactorings are good, but I'm not sure that we really want to go down the path of having entity instances that are shared between threads. <steve> I didn't think I implied such a thing. All I'm talking about here is furthering the concept of further breaking down the SessionImpl into a series of collaborators. I have not, and don't intend, to have these shared between sessions. Breaking the various functionalities apart in this manner just makes it easier to assemble sessions that behave differently based on the collaborators they use. </steve> If you want to have shared immutable objects, use a UserType, reference data is a slightly similar problem to the one described here: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/06/23#i18n I have personally used UserTypes to solve the problem of reference data in an application and it works very well. -- Gavin King +61 410 534 454 +1 404 822 8349 callto://gavinking Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] http://jboss.com ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
