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

[Madhumita Sadhukhan]

Hi Steve and Guenther,

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.

----I have set <natural-id mutable=\"true\"> in the mapping.I agree Steve's explanation justifies behaviour in step6.

>>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.

----I support that this fix should concern mutable natural ids only.


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.

----If it is decided to fix this even I would vote for this.The current situation is really confusing as we are able to load by the modified natural ids and that returns the older cached entity whereas the load by older natural id values is returning null.It will be good idea to get rid of this inconsistency.


Ok, but how is this testing anything about "jpa/hibernate integration
... in AS7"?  Its like building a Spring app to test String.format; its
just confusing overkill.

---Steve,my apologies for the confusion.I was only re-using our existing integration tests(for 2Lcache using hibernate native-api) to test if the new feature works in AS7/EAP6 or has broken anything(currently it is indeed broken in AS7 for HHH-7253); when I chanced upon this and thought worth discussion.

Thanks and Regards,
Madhumita Sadhukhan
JBoss EAP QE Team
Red Hat Brno




----- Original Message -----
From: "Guenther Demetz" <Guenther.Demetz at wuerth-phoenix.com>
To: "Steve Ebersole" <steve at hibernate.org>
Cc: "Madhumita Sadhukhan" <msadhukh at redhat.com>, "hibernate-dev at lists.jboss.org hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Monday, April 30, 2012 10:56:44 PM
Subject: AW: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?

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.