Steve Ebersole wrote:
I recently changed how this works a little bit and the current implementationThe 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.
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.
Refactorings are good, but I'm not sure that we really want to go down the
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).
path of having entity instances that are shared between threads. 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
