[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (HHH-7206) Manage natural-id synchronization without flushing

[ https://hibernate.onjira.com/browse/HHH-7206?page=com.atlassian.jira.plug... ] Guenther Demetz edited comment on HHH-7206 at 4/3/12 7:30 AM: -------------------------------------------------------------- Hi Steve, I'm already aware of this, just not noticed it yet here, because I tried to be as sintetic as possible and because also hibernate4.1.1 does call autoFlushIfRequired() in resolveNaturalId even if natural id is immutable, so that's a todo which has to do be fixed anyway. Other sessions do never pick up uncommitted changes from the second level cache (that would be a big issue indeed)! -in the case you use 2L-Cache with transactional CacheConcurrencyStrategy for example Infinispan the other session always see last commited cache entry (InfiniSpan is a multi-version-capable cache for this purpose) -in the case you use 2L-Cache with read-write CacheConcurrencyStrategy the cached entry gets locked until the end of the transaction so that other sessions don't pick up an uncommited value. It is true, that the proposed change is updating the second level cache rather early, but as the user is more likely to commit rather than rollback his transaction finally, this should not be a problem. Last but not least also a regular flush could occur already in the first phases of a transaction, with the identical effects, true or not? Sorry, but I cannot follow your argumentation: even if we would write just the natural-id changes to the database, on every next flush that entity gets again checked for dirtiness anyway. Writing just the detected natural-id changes immediately to the database, don't saves hiberante from absolutely nothing in terms of total work amount IMO, in contrary: you would split up the changes in more parts needing in total up to 2 update-executions instead to a single one. If you insist, we can also write just the detected natural-id changes immediately, but surely not if session flushMode is set to flushmode < AUTO, because otherwise, as already mentioned above, we would break the long conversation patterns which base in no implicit flushes occuring until the last transaction. In-line natural-id mutation handling is of basic importance for all users applying the long conversation patterns. The long conversation pattern should really not be a foreign use-case to you. Also the concept of pre-fetching all interested entities into context with less as possible database-hits, is suggested practice in hibernate documentation, so the use-case I have shown should not be that particular foreign. Basically that what I want ask you and Eric is: How should hibernate users applying the long conversation patterns (session.flushMode set to < AUTO) benefit from the new NaturalId feature? Currently the new apis are pretty useless in this context because transactional changes are not considered. As the NaturalIdLoad feature is brand new, now we are still in time to define how it should work. What are your concrete fears, in implementing a in-line natural-id mutation handling for all use-cases? Finally all proposed enhancements are strictly concerning the NaturalId handling, nothing else, so all other stuff works as before: I let run the matrix-tests today with the proposed changes and, except the tests regarding NaturalId which obviously have to be adapted, the rest ran witoud failures: {code} ... :hibernate-core:processMatrixResources UP-TO-DATE :hibernate-core:matrixClasses :hibernate-core:matrixUnitTest Test org.hibernate.test.naturalid.immutableentity.ImmutableEntityNaturalIdTest FAILED Test org.hibernate.test.naturalid.inheritance.InheritedNaturalIdTest FAILED Test org.hibernate.test.naturalid.mutable.MutableNaturalIdTest FAILED Test org.hibernate.test.naturalid.mutable.cached.CachedMutableNaturalIdTest FAILED 3037 tests completed, 5 failures {code} I understand that along classic flushing, in-line natural-id mutation handling would represent a complete new approach of synchronization process, but I think it is worth to be implemented and maintained. Last but not least also users using flushmode AUTO would benefit from this new architecture in terms of performance, as hibernate gets saved from having to scan the entire persistence context for dirty-changes on each NaturalId load access. I understand that you as project maintainer, are mainly concerned about hibernate being working correctly, anyway I hope there are other hibernate-developers attributing some importance to performance aspects too. was (Author: pb00067): Hi Steve, I'm already aware of this, just not noticed it yet here, because I tried to be as sintetic as possible and because also hibernate4.1.1 does call autoFlushIfRequired() in resolveNaturalId even if natural id is immutable, so that's a particularity which has to do be fixed anyway. Other sessions do never pick up uncommitted changes from the second level cache (that would be a big issue indeed)! -in the case you use 2L-Cache with transactional CacheConcurrencyStrategy for example Infinispan the other session always see last commited cache entry (InfiniSpan is a multi-version-capable cache for this purpose) -in the case you use 2L-Cache with read-write CacheConcurrencyStrategy the cached entry gets locked until the end of the transaction so that other sessions don't pick up an uncommited value. It is indeed true, that the proposed change is updating the second level cache rather early, but as the user is more likely to commit rather than rollback his transaction finally, this should not be a problem. Last but not least also a regular flush could occur already in the first phases of a transaction, with the identical effects, true or not? Sorry, but I cannot follow your argumentation: even if we would write just the natural-id changes to the database, on every next flush that entity gets again checked for dirtiness anyway. Writing just the detected natural-id changes immediately to the database, don't saves hiberante from absolutely nothing in terms of total work amount IMO, in contrary: you would split up the changes in more parts needing in total up to 2 update-executions instead to a single one. If you insist, we can also write just the detected natural-id changes immediately, but surely not if session flushMode is set to flushmode < AUTO, because otherwise, as already mentioned above, we would break the long conversation patterns which trust in no implicit flushes occuring. As the NaturalIdLoad feature is brand new, now we are still in time to define how it should work. Which kind of troubles do you see concretely with a natural-id mutation in-line within other use-cases? In-line natural-id mutation handling is of basic importance for all users applying the long conversation patterns. The long conversation pattern should really not be a foreign use-case to you. Also the concept of pre-fetching all interested entities into context with less as possible database-hits, is suggested practice in hibernate documentation, so the use-case I have shown should not be that particular foreign. Basically that what I want ask you and Eric is: How should hibernate users applying the long conversation patterns (session.flushMode set to < AUTO) benefit from the new NaturalId feature? Currently the new apis are pretty useless in this context because transactional changes are not considered. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira