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-boun...@lists.jboss.org [mailto:hibernate-dev-boun...@lists.jboss.org] On Behalf Of Madhumita Sadhukhan Sent: Friday, April 27, 2012 4:15 PM To: hibernate-dev@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" To: "Strong Liu" 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 Sadhu
Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?
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/basic/src/test/java/org/jboss/as/test/integration/hibernate/naturalid/HibernateNativeAPINaturalId2LCachingTestCase.java 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" To: "Madhumita Sadhukhan" , "hibernate-dev@lists.jboss.org hibernate-dev" 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-boun...@lists.jboss.org [mailto:hibernate-dev-boun...@lists.jboss.org] On Behalf Of Madhumita Sadhukhan Sent: Friday, April 27, 2012 4:15 PM To: hibernate-dev@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" To: "Strong Liu" 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/bas
[hibernate-dev] Hibernate Validator 4.3.0.CR1 is out
More on in.relation.to - http://in.relation.to/Bloggers/HibernateValidator430CR1 --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Adding features to Dialect class
Could this be a common enough issue that Hibernate includes a
work-around type so that everyone doesn't have to write their own?
We've had to address this wonderful Oracle "feature" via a custom user
type as well, ours is based on http://usertype.sourceforge.net/ and the
NullSafeStringType and NullSafeStringColumnMapper are available here:
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/dao/usertype/
Our approach is that any non-null string gets prefixed with _ when
stored in the DB
-Eric
On 04/23/2012 01:23 PM, Steve Ebersole wrote:
> Personally I think people relying on this Oracle (mis-)behavior are
> just asking for problems.
>
> But lets say people do agree that we should handle this... so you add a
> method to Dialect to handle detect this environment... how do you plan
> on checking it? Today it is the Types that are responsible for
> equality checking (I assume that is what Envers uses as well). So I am
> just suggesting that the user supplying a custom
> FunkyOracleStringVarcharType Type implementation is probably a better
> option. Unless I misunderstand how Envers is doing the equality
> checking and y'all do not use Types for that.
>
> On Mon 23 Apr 2012 11:18:44 AM CDT, Łukasz Antoniak wrote:
>> Totaly agree that expecting null to be equal to empty string in Java model
>> is wrong.
>>
>> IMO he has spotted that when null string reference is replaced with an empty
>> string, Envers creates new revision. From database
>> perspective (Oracle) two records does not differ in any way. This could be
>> actually handled easily in Envers code. I thought that
>> it would be more elegant to add new dialect feature, but if this behavior is
>> special to Oracle, there is no need.
>>
>> // Revision 1
>> em.getTransaction().begin();
>> StrTestEntity emptyEntity = new StrTestEntity("");
>> em.persist(emptyEntity);
>> em.getTransaction().commit();
>> // Should not generate revision after NULL to "" modification on Oracle. But
>> now it does.
>> em.getTransaction().begin();
>> emptyEntity = em.find(StrTestEntity.class, emptyId);
>> emptyEntity.setStr(null);
>> em.merge(emptyEntity);
>> em.getTransaction().commit();
>>
>> Will use dev mailing list. Sorry for that.
>>
>> Steve Ebersole wrote:
>>> Their better option is to apply a Type for String that handles this.
>>>
>> http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html_single/#types-registry
>>>
>>> This is the type of thing we will be able to handle automatically in
>> 5.0
>>>
>>> But as for the forum user's exact question, personally I think him
>>> expecting null and empty string *in the java model* to be handled
>>> equally is just plain wrong.
>>>
>>> P.S., these kinds of questions should be directed at the dev list so
>> we
>>> can get everyone's input.
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> --
> st...@hibernate.org
> http://hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?
Thank you Madhumita , finally I was able to reproduce all steps. Whilst point 6 represents definitely a bug (I opened https://hibernate.onjira.com/browse/HHH-7287) I'm not so sure about point 5: the NaturalIdLoadAccess's internal query does 'see' the new values, when the used isolation level is lesser than SERIALIZABLE and therefore return a result. The question here is something to discuss , in my opinion,is. Is whether: - NaturalIdLoadAccess should act like the persistent context's repeatable-read behavior, and thus return null in case that the search-natural-id-values differ from the ones in the according entity state. or if - NaturalIdLoadAccess should act like a plain query api and thus return the entity even if the search-natural-id-values differ from the ones in the current entity state. best regards Guenther -Original Message- From: Madhumita Sadhukhan [mailto:msadh...@redhat.com] Sent: Monday, April 30, 2012 11:32 AM To: Demetz, Guenther; Steve Ebersole Cc: hibernate-dev@lists.jboss.org hibernate-dev Subject: Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected? 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/basic/src/test/java/org/jboss/as/test/integration/hibernate/naturalid/HibernateNativeAPINaturalId2LCachingTestCase.java 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" To: "Madhumita Sadhukhan" , "hibernate-dev@lists.jboss.org hibernate-dev" 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-boun...@lists.jboss.org [mailto:hibernate-dev-boun...@lists.jboss.org] On Behalf Of Madhumita Sadhukhan Sent: Friday, Ap
Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?
The problem with this analogy is that really what is being tried here is much more like changing the entity's primary key behind the scenes. Hibernate wont clean up cache entries (persistence context nor L2C) in that case either. Like I said before, IMO this is really just a bad use case. He is asking for the shared caching (L2C) of something that he *knows* is going to change in the database. Could HIbernate handle it? Sure. The question is whether its worthwhile. Obviously if we do decide to do this it should be limited to just mutable natural ids. On Mon 30 Apr 2012 08:30:51 AM CDT, Demetz, Guenther wrote: > Thank you Madhumita , finally I was able to reproduce all steps. > > Whilst point 6 represents definitely a bug (I opened > https://hibernate.onjira.com/browse/HHH-7287) > I'm not so sure about point 5: > the NaturalIdLoadAccess's internal query does 'see' the new values, when the > used isolation level is lesser than SERIALIZABLE and therefore return a > result. > > The question here is something to discuss , in my opinion,is. > Is whether: > > - NaturalIdLoadAccess should act like the persistent context's > repeatable-read behavior, >and thus return null in case that the search-natural-id-values differ from > the ones in the according entity state. > > or if > > - NaturalIdLoadAccess should act like a plain query api and thus return the > entity >even if the search-natural-id-values differ from the ones in the current > entity state. > > > best regards > Guenther > > > -Original Message- > From: Madhumita Sadhukhan [mailto:msadh...@redhat.com] > Sent: Monday, April 30, 2012 11:32 AM > To: Demetz, Guenther; Steve Ebersole > Cc: hibernate-dev@lists.jboss.org hibernate-dev > Subject: Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is > this expected? > > 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/basic/src/test/java/org/jboss/as/test/integration/hibernate/naturalid/HibernateNativeAPINaturalId2LCachingTestCase.java > > 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" > To: "Madhumita Sadhukhan", > "hibernate-dev@lists.jboss.org hibernate-dev" > 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.
Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?
On 04/30/2012 04:32 AM, Madhumita Sadhukhan wrote: > 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. 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. Plus see my comments in my other reply. -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fwd: NaturalIdLoadAccess behaviour on 2Lcache is this expected?
On 04/30/2012 08:30 AM, Demetz, Guenther wrote: > Whilst point 6 represents definitely a bug (I opened > https://hibernate.onjira.com/browse/HHH-7287) Well, again, I am not so sure this is a bug. First, in the test you go out of your way to mix transactional and non-transactional access to the database. If you change your non-transactional access to instead be transactional, it works. Your in-line comments mention something about SERIALZABLE txn isolation, but this is against H2 and just using (default) READ COMMITTED. I am not a fan of writing tests with and developing solutions based on non-transactional access. 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. -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [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. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
