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

[ https://hibernate.onjira.com/browse/HHH-7206?page=com.atlassian.jira.plug... ] Guenther Demetz commented on HHH-7206: -------------------------------------- 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 practise 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