Hello Steve and Guenther,
Thanks for sparing some time to look into this.
The entitymapping information for Person is in file
HibernateNativeAPINaturalId2LCachingTestCase.java in string testmapping.
For convenience I have uploaded the test to my AS7 github as follows:
https://github.com/madhumita12/jboss-as/blob/master/testsuite/integration...
Files you need to look at:
HibernateNativeAPINaturalId2LCachingTestCase.java
SFSB2LcacheNaturalId.java
Person.java
This testcase will fail in this branch as it uses hibernate 4.1.2 and in order to run it
successfully you could just replace with 4.1.3 hibernate jars after building this branch.
I have tried to put adequate comments to express my location of confusion.
Steve,
I am following the normal pattern followed by most jpa/hibernate integration testcases in
AS7 where the methods/actions involving the Transaction or Session is handled in the
(SF/SL)Session Bean which in turn is invoked from the main testcase that prepares the
archive and deploys the ear ,invokes the tests with conclusions in assertions.
Guenther,
I agree with your reasoning for steps 5 and step 7 as I am using Container Managed
Transaction where isolation level (if it is not defined) picks up the default for the
underlying Database which is inbuilt H2 for AS7 in this case and default isolation used
for H2 is read-committed.
However as I have already explained in my previous mail I am rather confused/concerned
with the discrepancy in behaviour between step 5 and step 6 as step 6 returns me null when
I use the same NaturalIdLoadAccess object to load the entity using previous values which
looks inconsistent!
Thanks and Regards,
Madhumita Sadhukhan
JBoss EAP QE Team
Red Hat Brno
----- Original Message -----
From: "Guenther Demetz" <Guenther.Demetz(a)wuerth-phoenix.com>
To: "Madhumita Sadhukhan" <msadhukh(a)redhat.com>,
"hibernate-dev(a)lists.jboss.org hibernate-dev"
<hibernate-dev(a)lists.jboss.org>
Sent: Monday, April 30, 2012 9:16:44 AM
Subject: RE: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this
expected?
Hi Madhumita Sadhukhan,
although I did not receive your attachments,
please allow me to make some considerations to point 5 and successive:
point 5:
When you load using updated natural-ids values, it should depend on the isolation level
you use, whether you retrieve a result or not.
With levels REPEATABLE_READ of SERIALIZEABLE there should be no result, since the
update-transaction begun after you already read concerning record
in your main transaction.
With READ_COMMITED or lower isolation you have a result, but this will not update the
values in your persistent context as it simulates repeatable-read for entities. This is a
well-documented behavior, explained in book Java Persistence with Hibernate, chapter 9.1.2
The persistent context, here a snippet from:
... Hibernate reads the result set of the query and marshals entity objects that are then
returned to the application. During this process, Hibernate interacts with the current
persistence context. It tries to resolve every entity instance in this cache (by
identifier); only if the instance can’t be found in the current persistence context does
Hibernate read the rest of the data from the result set. It tries to resolve every entity
instance in this cache (by identifier); only if the instance can’t be found in the current
persistence context does Hibernate read the rest of the data from the result set.
This may explain the behavior in point 5 and 7, does it?
(Indeed I was not able to reproduce point 6, I'm not getting a null as result.)
regards
G.D.
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org [mailto:hibernate-dev-bounces@lists.jboss.org]
On Behalf Of Madhumita Sadhukhan
Sent: Friday, April 27, 2012 4:15 PM
To: hibernate-dev(a)lists.jboss.org hibernate-dev
Subject: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?
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(a)redhat.com>
To: "Strong Liu" <stliu(a)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