Hi Steve, hi Madhumita, >> If you change your non-transactional access to instead be transactional, it >> works. Yes, that's true (thanks to the new paradigma with inline natural-id sync processing).
Madhumita, can you please confirm, that also your test-case is using non-transactional access in points 5,6,7? If not, then I guess, that you forgot to mark the natural-id as mutable in the mapping of Person, otherwise the behaviour in point 6 is a mystery to me. >>Your in-line comments mention something about SERIALZABLE txn isolation, but >>this is against H2 and just using (default) READ COMMITTED. Maybe my comments were not clear enough, that what I wanted to say is: the bug would not rise using SERIALZABLE txn isolation (if the database engine would support that), it shows up indeed with using READ COMMITTED. >>Anyway, like I said in one of my earlier replies, Hibernate could >>certainly support this use case if thats what we all decide it should. >>But I will limit this to natural ids mapped as mutable. The reason >>being that there will be alot of overhead in supporting this correctly >>and it is really only relevant for mutable natural ids. Developers who >>have developed their apps to leverage non-mutable natural ids should not >>suffer in this perf hit. Im perfectly agree with this sentences above, this all concerns only mutable natural ids. Just let me please express a further idea, Steve, in case that it will be decided, to do the fix: if we would also decide to return null in case that the search-natural-id-values differ from the ones in the according entity state (see proposal from my previous mail), then this would also render superflous the unpleasant mechanism of stashing invalid natural-id values you were forced to introduce recently. Just as a thought. regards G.D. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
