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

Fri Apr 27 12:48:42 EDT 2012

Sorry for spamming but seems like attached files are screened and finally does not make it to hibernate-dev-list.
I will upload this on github and then get back on this.

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

----- Original Message -----
From: "Madhumita Sadhukhan" <msadhukh at redhat.com>
To: "Steve Ebersole" <steve at hibernate.org>
Cc: "hibernate-dev at lists.jboss.org hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Friday, April 27, 2012 6:40:40 PM
Subject: Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache	is this expected?

Steve,

         I did attach the piece of code and log and its showing in my sent items.I am surprised why the attachment did not make it(as the size is few kbs).
I will try again and I hope it makes it this time(attached files) .

And by loader I meant an instance of NaturalIdLoadAccess(which will be clear if you can take a look at the code).

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

----- Original Message -----
From: "Steve Ebersole" <steve at hibernate.org>
To: "Madhumita Sadhukhan" <msadhukh at redhat.com>
Cc: "hibernate-dev at lists.jboss.org hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Friday, April 27, 2012 4:47:33 PM
Subject: Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?

I have no idea what "load by loader" means.  "Loader" to Hibernate 
developers means something much different than I am assuming you mean...

Also, I see no attachment...

First and foremost, I'd argue that your use case here is just plain 
broken.  Just like with entity data, second-level caching data that you 
fully expect to change "under the covers" is just asking for problems.  
That being said, we should certainly try to handle the situation here 
*it if it makes sense*.  But thats hard to ascertain without the logs 
or the mapping or something.

I assume the entity itself is also cached?  Thats the only way I can 
make sense out of what I think you are doing in (5)

On Fri 27 Apr 2012 09:14:31 AM CDT, Madhumita Sadhukhan wrote:
> Hello Developers,
>
>             Strong suggested I fwd this to the mailing-list.With reference to mail below could any of you clarify/explain if this is expected behaviour of NaturalIdLoadAccess with 2lcache as I find some discrepancy.
>
> Thanks and Regards,
> Madhumita Sadhukhan
> JBoss EAP QE Team
> Red Hat Brno
>
>
>
>
> ----- Forwarded Message -----
> From: "Madhumita Sadhukhan"<msadhukh at redhat.com>
> To: "Strong Liu"<stliu at redhat.com>
> Sent: Friday, April 27, 2012 12:19:18 AM
> Subject: NaturalIdLoadAccess behaviour is this expected?
>
> Hi Strong,
>
>          I notice a strange behaviour while loading natural id with secondlevel cache enabled.
> Not sure if this is expected behaviour but I notice some discrepancies which I would like to clarify.
> I am not yet uploading this test to my AS7 branch on github as AS7 is still stuck on hibernate4.1.2 and this test requires 4.1.3 from EAP 6 tested currently to work.
> Please paste the attached unzipped folder in AS testsuite folder structure in location:
>
> /jboss-as/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/hibernate/
>
> Please run with hibernate 4.1.3 jars replaced in modules/org/hibernate..... within build of AS7
>
> In my test I have tried to load an entity with NaturalIdLoadAccess while 2lcache is enabled using two natural ids(firstname and voterid) in several steps.
>
> 1) create person(with natural ids firstname and voterid)
> 2) load using natural ids first time
> 3) modify/update natural ids in database(in order to not touch 2lcache)
> 4) load using loader from 2Lcache using old natural id values in step 2---//this works correctly as expected and is able to load values from cache though it has been modified in DB.
> 5) then load using loader from (2) but using updated values of firstname and voterid(naturalids) used in step 3
> //this is where it breaks the Person object returned from this load still shows older value of firstname as in step 2 but wondering how the loader works as I have passed the new values in using(....)
> also the next step fails so wondering where the flaw is!
>
> 6) try to use same loader and load using older values of natural id this is to recheck if older value is still persisting in cache as it was returned in step5
> //this returns null pointer showing it does not exist in cache and loader is unable to load it!
>
> 7) If i try again with the new actual values the loader is able to load the person entity again but with old values!!!
>
>
> So the problem/confusion is due to the discrepancy between step 5 and step 6 (with the older value of entity loaded in step5 indicating it is still cached but then with the failure to load it in step 6 throwing nullpointer which indicates its not)
> Also I am surprised at how using() function behaves on the loader i.e it returns the entity with older values while loading "using()" the updated values!(as confirmed in step 7)
>
> Please note that the testcase will pass as I replaced the asserts with S.O.Ps hence you should check for the values in server log excerpt(attaching for ease)
>
>
> Could you take a quick look please and explain if this is expected behaviour?
>
>
> Thanks and Regards,
> Madhumita Sadhukhan
> JBoss EAP QE Team
> Red Hat Brno
>
>
>
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
steve at hibernate.org
http://hibernate.org

_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev