[hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?

[Demetz, Guenther]

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.