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.