Re: [hibernate-dev] Hibernate ORM 4.1.1 release - Undocumented behavior change in Optimistic Versioning ?

[Demetz, Guenther]

Hi hibernate developers,

testing Hibernate ORM 4.1.1 I discovered a behavior change regarding Optimistic 
Lock Versioning
in detail on bidirectional OneToMany relations with inverse-owner (mappedBy 
attribute specified):

- until Hiberante version 4.1.0 by default on changes both involved sides got a 
version increment 
- now with Hiberante4.1.1 only the owner-side (=the Many-side) gets a version 
increment.

To make the thing working as before, 
now on such relations we must define explicitly OptimisticLock.excluded=false 

@javax.persistence.OneToMany(mappedBy = "parent")
@org.hibernate.annotations.OptimisticLock(excluded=false)
@javax.persistence.MapKey(name="field1")
private Map aggChild = new java.util.HashMap();

Was such behavior change intended?
I looked at the 28 issues which had been fixed with Hiberante4.1.1 but found 
nothing in regard,
maybe I overlooked something ?


Würth Phoenix S.r.l.
Günther Demetz
Via Kravogl 4
I-39100 Bolzano 
E-Mail: guenther.dem...@wuerth-phoenix.com
Website:  www.wuerth-phoenix.com



___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Galder Zamarreño]

Steve,

Just built it and I see no such folders in my env:
https://gist.github.com/2005857

Maybe these are old folders that were lying around?

They look to be JBoss Transactions related.

Cheers,

On Mar 8, 2012, at 1:53 AM, Steve Ebersole wrote:

> Running the hibernate-infinispan tests I am seeing 2 output directories 
> showing up in the hibernate-infinispan directory (aka, not 
> hibernate-infinispan/target/...).  Namely, I see 
> hibernate-infinispan/ObjectStore and 
> hibernate-infinispan/PutObjectStoreDirHere.  Anyone know how/if we can 
> change where those directories get created?
> 
> -- 
> st...@hibernate.org
> http://hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Galder Zamarreño]

My build, including running tests, took:

Total time: 2 mins 53.136 secs

So, I'd say it's some env issue, maybe UDP traffic generated by the cluster 
tests getting stuck somewhere?

Btw, I did improve the speed of these tests hugely a few months ago by 
switching to an in-memory discovery protocol (TEST_PING) that had worked pretty 
well in Infinispan.

On Mar 8, 2012, at 2:04 AM, Steve Ebersole wrote:

> Speaking of which, is everyone else seeing tests in 
> hibernate-infinispan taking many many minutes to run?
> 
> On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
>> Running the hibernate-infinispan tests I am seeing 2 output 
>> directories showing up in the hibernate-infinispan directory (aka, not 
>> hibernate-infinispan/target/...). Namely, I see 
>> hibernate-infinispan/ObjectStore and 
>> hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we can 
>> change where those directories get created?
>> 
> 
> -- 
> st...@hibernate.org
> http://hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Galder Zamarreño]

My bad, I'll do that right away. CR1 was released just 3 days before FINAL, so 
it's pretty stable already.

On Mar 8, 2012, at 2:56 AM, Steve Ebersole wrote:

> Hmm, I did not have problems resolving artifacts, but I just noticed 
> this CR... we really need to not be upgrading to CR releases of 
> dependencies as part of a point release.  Sigh
> 
> On Wed 07 Mar 2012 08:19:55 PM CST, Strong Liu wrote:
>> btw ci fails due to
>> 
>> 08:23:54.474 [ERROR] [org.gradle.BuildExceptionReporter] Could not 
>> resolve all dependencies for configuration 
>> ':hibernate-infinispan:testCompile'.
>> 08:23:54.478 [ERROR] [org.gradle.BuildExceptionReporter]>  Artifact 
>> 'org.infinispan:infinispan-core:5.1.2.CR1:tests@jar' not found.
>> 
>> -
>> Best Regards,
>> 
>> Strong Liu http://hibernate.org/>>
>> http://about.me/stliu/bio
>> 
>> On Mar 8, 2012, at 10:04 AM, Steve Ebersole wrote:
>> 
>>> Speaking of which, is everyone else seeing tests in
>>> hibernate-infinispan taking many many minutes to run?
>> 
>> 
>> yes, it reallly takes some time
>> 
>>> 
>>> On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
 Running the hibernate-infinispan tests I am seeing 2 output
 directories showing up in the hibernate-infinispan directory (aka, not
 hibernate-infinispan/target/...). Namely, I see
 hibernate-infinispan/ObjectStore and
 hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we can
 change where those directories get created?
 
>>> 
>>> -- 
>>> st...@hibernate.org 
>>> http://hibernate.org
>>> ___
>>> 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

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Galder Zamarreño]

Not Infinispan, but JBoss Transactions.

On Mar 8, 2012, at 9:15 AM, Hardy Ferentschik wrote:

> This used to happen in Search as well, but is gone now (I think). Must be in 
> Infinispan config thing. 
> Sanne probably knows :-)
> 
> --Hardy
> 
> 
> On Mar 8, 2012, at 2:53 AM, Steve Ebersole wrote:
> 
>> Running the hibernate-infinispan tests I am seeing 2 output directories 
>> showing up in the hibernate-infinispan directory (aka, not 
>> hibernate-infinispan/target/...).  Namely, I see 
>> hibernate-infinispan/ObjectStore and 
>> hibernate-infinispan/PutObjectStoreDirHere.  Anyone know how/if we can 
>> change where those directories get created?
>> 
>> -- 
>> 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

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Galder Zamarreño]

On Mar 8, 2012, at 10:48 AM, Sanne Grinovero wrote:

> Hi,
> I found the same files in my workspace as left over from and older
> build, but deleted them and tried new builds several times, they don't
> seem to be re-created anymore?
> Could anyone confirm (after cleaning them up) that it's still a
> problem, as I can't..
> 
> On the build issues, I had to rebuild and install locally
> infinispan-5.1.2.CR1 as it seems it couldn't find the test jars in
> Maven repositories.

Why? See: 
https://repository.jboss.org/nexus/content/groups/public/org/infinispan/infinispan-core/5.1.2.CR1/

Again, Smells like a bug in Gradle/Ivy - we had no complaints on tests jars.

> 
> @Steve, regarding the upgrade of Infinispan in a minor release; is
> your concern the fact that it's not a Final version or is it about not
> changing any dependency version?
> As Infinispan 5.1.2.FINAL was released as well, so you could move forward.
> 
> I had no other test failures.
> 
> -- Sanne
> 
> On 8 March 2012 10:34, Hardy Ferentschik  wrote:
>> Hi,
>> 
>> it just took 5 attempts to build everything :-(
>> 
>> The first two times I got errors due to unresolved dependencies (first time 
>> some docbook stuff, then Infinispan).
>> In both cases the problem went away by restarting the build.
>> 
>> The third time around I got a test failure in 
>> org.hibernate.test.annotations.onetoone.OneToOneTest. No idea why.
>> 
>> The forth time around 
>> org.hibernate.envers.test.integration.components.PropertiesGroupTest failed.
>> I've seen this test fail before (also on the metamodel branch I believe). 
>> Does anyone else see this test fail at times?
>> 
>> The fifth time the build completed successfully. I can confirm that the 
>> infinispan module creates some artifacts outside
>> of the build directory ObjectStore and  PutObjectStoreDirHere. I don't think 
>> the tests ran any slower than they used to.
>> 
>> Total build time for me (according to gradle) was 11 mins 1.78 secs
>> 
>> I find the "random" test errors worrying though. Anyone experiencing them as 
>> well?
>> 
>> --Hardy
>> 
>> 
>> On Mar 8, 2012, at 3:56 AM, Steve Ebersole wrote:
>> 
>>> Hmm, I did not have problems resolving artifacts, but I just noticed
>>> this CR... we really need to not be upgrading to CR releases of
>>> dependencies as part of a point release.  Sigh
>>> 
>>> On Wed 07 Mar 2012 08:19:55 PM CST, Strong Liu wrote:
 btw ci fails due to
 
 08:23:54.474 [ERROR] [org.gradle.BuildExceptionReporter] Could not
 resolve all dependencies for configuration
 ':hibernate-infinispan:testCompile'.
 08:23:54.478 [ERROR] [org.gradle.BuildExceptionReporter]>  Artifact 
 'org.infinispan:infinispan-core:5.1.2.CR1:tests@jar' not found.
 
 -
 Best Regards,
 
 Strong Liu http://hibernate.org/>>
 http://about.me/stliu/bio
 
 On Mar 8, 2012, at 10:04 AM, Steve Ebersole wrote:
 
> Speaking of which, is everyone else seeing tests in
> hibernate-infinispan taking many many minutes to run?
 
 
 yes, it reallly takes some time
 
> 
> On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
>> Running the hibernate-infinispan tests I am seeing 2 output
>> directories showing up in the hibernate-infinispan directory (aka, not
>> hibernate-infinispan/target/...). Namely, I see
>> hibernate-infinispan/ObjectStore and
>> hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we can
>> change where those directories get created?
>> 
> 
> --
> st...@hibernate.org 
> http://hibernate.org
> ___
> 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
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Galder Zamarreño]

On Mar 8, 2012, at 4:46 PM, Strong Liu wrote:

> 
> On Mar 8, 2012, at 6:48 PM, Sanne Grinovero wrote:
> 
>> Hi,
>> I found the same files in my workspace as left over from and older
>> build, but deleted them and tried new builds several times, they don't
>> seem to be re-created anymore?
>> Could anyone confirm (after cleaning them up) that it's still a
>> problem, as I can't..
>> 
>> On the build issues, I had to rebuild and install locally
>> infinispan-5.1.2.CR1 as it seems it couldn't find the test jars in
>> Maven repositories.
> 
> this also causes our master job fail
> 
> Galder, how should we fix it?

Abandon Gradle and move to Maven? ;)

On a more serious note, I don't really know. Maybe the maven repository CI uses 
is corrupt?

> 
>> 
>> @Steve, regarding the upgrade of Infinispan in a minor release; is
>> your concern the fact that it's not a Final version or is it about not
>> changing any dependency version?
>> As Infinispan 5.1.2.FINAL was released as well, so you could move forward.
>> 
>> I had no other test failures.
>> 
>> -- Sanne
>> 
>> On 8 March 2012 10:34, Hardy Ferentschik  wrote:
>>> Hi,
>>> 
>>> it just took 5 attempts to build everything :-(
>>> 
>>> The first two times I got errors due to unresolved dependencies (first time 
>>> some docbook stuff, then Infinispan).
>>> In both cases the problem went away by restarting the build.
>>> 
>>> The third time around I got a test failure in 
>>> org.hibernate.test.annotations.onetoone.OneToOneTest. No idea why.
>>> 
>>> The forth time around 
>>> org.hibernate.envers.test.integration.components.PropertiesGroupTest failed.
>>> I've seen this test fail before (also on the metamodel branch I believe). 
>>> Does anyone else see this test fail at times?
>>> 
>>> The fifth time the build completed successfully. I can confirm that the 
>>> infinispan module creates some artifacts outside
>>> of the build directory ObjectStore and  PutObjectStoreDirHere. I don't 
>>> think the tests ran any slower than they used to.
>>> 
>>> Total build time for me (according to gradle) was 11 mins 1.78 secs
>>> 
>>> I find the "random" test errors worrying though. Anyone experiencing them 
>>> as well?
>>> 
>>> --Hardy
>>> 
>>> 
>>> On Mar 8, 2012, at 3:56 AM, Steve Ebersole wrote:
>>> 
 Hmm, I did not have problems resolving artifacts, but I just noticed
 this CR... we really need to not be upgrading to CR releases of
 dependencies as part of a point release.  Sigh
 
 On Wed 07 Mar 2012 08:19:55 PM CST, Strong Liu wrote:
> btw ci fails due to
> 
> 08:23:54.474 [ERROR] [org.gradle.BuildExceptionReporter] Could not
> resolve all dependencies for configuration
> ':hibernate-infinispan:testCompile'.
> 08:23:54.478 [ERROR] [org.gradle.BuildExceptionReporter]>  Artifact 
> 'org.infinispan:infinispan-core:5.1.2.CR1:tests@jar' not found.
> 
> -
> Best Regards,
> 
> Strong Liu http://hibernate.org/>>
> http://about.me/stliu/bio
> 
> On Mar 8, 2012, at 10:04 AM, Steve Ebersole wrote:
> 
>> Speaking of which, is everyone else seeing tests in
>> hibernate-infinispan taking many many minutes to run?
> 
> 
> yes, it reallly takes some time
> 
>> 
>> On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
>>> Running the hibernate-infinispan tests I am seeing 2 output
>>> directories showing up in the hibernate-infinispan directory (aka, not
>>> hibernate-infinispan/target/...). Namely, I see
>>> hibernate-infinispan/ObjectStore and
>>> hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we can
>>> change where those directories get created?
>>> 
>> 
>> --
>> st...@hibernate.org 
>> http://hibernate.org
>> ___
>> 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
>> 
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Galder Zamarreño]

No idea why, the JAR is there - maybe a Gradle/Ivy issue?
https://repository.jboss.org/nexus/content/groups/public/org/infinispan/infinispan-core/5.1.2.CR1/infinispan-core-5.1.2.CR1-tests.jar

I don't get this issue in my own env btw.

On Mar 8, 2012, at 2:19 AM, Strong Liu wrote:

> btw ci fails due to 
> 
> 08:23:54.474 [ERROR] [org.gradle.BuildExceptionReporter] Could not resolve 
> all dependencies for configuration ':hibernate-infinispan:testCompile'.
> 08:23:54.478 [ERROR] [org.gradle.BuildExceptionReporter] > Artifact 
> 'org.infinispan:infinispan-core:5.1.2.CR1:tests@jar' not found.
> 
> -
> Best Regards,
> 
> Strong Liu 
> http://about.me/stliu/bio
> 
> On Mar 8, 2012, at 10:04 AM, Steve Ebersole wrote:
> 
>> Speaking of which, is everyone else seeing tests in 
>> hibernate-infinispan taking many many minutes to run?
> 
> 
> yes, it reallly takes some time
> 
>> 
>> On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
>>> Running the hibernate-infinispan tests I am seeing 2 output 
>>> directories showing up in the hibernate-infinispan directory (aka, not 
>>> hibernate-infinispan/target/...). Namely, I see 
>>> hibernate-infinispan/ObjectStore and 
>>> hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we can 
>>> change where those directories get created?
>>> 
>> 
>> -- 
>> 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

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] immutable can be deleted? and should readonly cache throw exception?

[Steve Ebersole]

Immutable entities should still be deletable.  Unless Gail changed that 
during the consolidation with making a particular entity instance "read 
only" as part of a session.  There was a lot of discussion at that time 
wrt consistency between these two things.  I forget all the outcomes.  
But immutable used to mean it could still be deleted.

HQL bulk deletes and updates circumvent normal modes of operation at 
many levels, caching being one of them.  It interacts with the cache in 
a much different way than a normal Session.delete.

Marking an entity with a cache access strategy of read-only is a bit 
different semantic.

+1000 about test method independence.  This has bitten us over and over 
again.

On Fri 09 Mar 2012 01:24:57 AM CST, Strong Liu wrote:
> Hi There,
>
> is an immutable entity can be deleted?
>
> according to 
> http://docs.jboss.org/hibernate/core/4.0/manual/en-US/html_single/
>
> "12.1.1. Entities of immutable classes"
>
> "An entity of an immutable class can created and deleted the same as an 
> entity of a mutable class."
>
> but "5.1.1 Entity" saying:
>
> "Some entities are not mutable. They cannot be updated or deleted by the 
> application. This allows Hibernate to make some minor performance 
> optimizations.. Use the @Immutable annotation."
>
> the reason i'm asking this is this test 
> org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest#testPolymorphism.
>
> when running testsuite on jdk 7, the order of methods returned by 
> getDeclaredMethods changed and can vary from run to run 
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7023180), so, the order 
> of each test case in a test class can't be guaranteed.
>
> so, we need each test case independent.
>
> clearly, this test case depends on the order.
>
> I added a cleanupTest method
>
>   @Override
>   protected void cleanupTest() throws Exception {
>   Session s = openSession();
>   s.beginTransaction();
>   List list = s.createQuery( "from java.lang.Object" ).list();
>   for(Object obj :  list){
>   s.delete( obj );
>   }
>   s.getTransaction().commit();
>   s.close();
>   }
>
> and get this exception:
>
> java.lang.UnsupportedOperationException: Can't write to a readonly object
>   at 
> org.hibernate.testing.cache.ReadOnlyEntityRegionAccessStrategy.lockItem(ReadOnlyEntityRegionAccessStrategy.java:68)
>   at 
> org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:84)
>   at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
>   at 
> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
>   at 
> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:280)
>   at 
> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
>   at 
> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
>   at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127)
>   at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:325)
>   at 
> org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101)
>   at 
> org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
>   at 
> org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest.cleanupTest(BasicHibernateAnnotationsTest.java:105)
>   
>
> btw, i'm also seeing this jira https://hibernate.onjira.com/browse/HHH-6329
>
> change the cleanupTest to use hql (s.createQuery("delete 
> java.lang.Object").executeUpdate();) runs successfully and no test failure.
>
> -
> Best Regards,u
>
> Strong Liu
> http://about.me/stliu/bio
>
> ___
> 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

Re: [hibernate-dev] Hibernate ORM 4.1.1 release - Undocumented behavior change in Optimistic Versioning ?

[Steve Ebersole]

The old behavior violated JPA spec.  The issue is HHH-7138


On Fri 09 Mar 2012 03:04:54 AM CST, Demetz, Guenther wrote:
> Hi hibernate developers,
>
> testing Hibernate ORM 4.1.1 I discovered a behavior change regarding 
> Optimistic Lock Versioning
> in detail on bidirectional OneToMany relations with inverse-owner (mappedBy 
> attribute specified):
>
> - until Hiberante version 4.1.0 by default on changes both involved sides got 
> a version increment
> - now with Hiberante4.1.1 only the owner-side (=the Many-side) gets a version 
> increment.
>
> To make the thing working as before,
> now on such relations we must define explicitly OptimisticLock.excluded=false
>
> @javax.persistence.OneToMany(mappedBy = "parent")
> @org.hibernate.annotations.OptimisticLock(excluded=false)
> @javax.persistence.MapKey(name="field1")
> private Map  aggChild = new java.util.HashMap();
>
> Was such behavior change intended?
> I looked at the 28 issues which had been fixed with Hiberante4.1.1 but found 
> nothing in regard,
> maybe I overlooked something ?
>
>
> Würth Phoenix S.r.l.
> Günther Demetz
> Via Kravogl 4
> I-39100 Bolzano
> E-Mail: guenther.dem...@wuerth-phoenix.com
> Website:  www.wuerth-phoenix.com
>
>

-- 
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] Infinispan tests

[Steve Ebersole]

Luckily you get to decide to follow the company line and use inferior 
tools as part of your project.

Considering that part works everywhere I find it funny that you can 
chalk my issue up to env but this has to be a "gradle/ivy bug" lol.

There is also a far easier syntax for how you are trying to pull in 
infinispan artifacts.  I'll work on updating that for you.

As for my "env issues", such as?  I'd really like my build to finish in 
less than an hour! :)


On Fri 09 Mar 2012 03:51:45 AM CST, Galder Zamarreño wrote:
>
> On Mar 8, 2012, at 4:46 PM, Strong Liu wrote:
>
>>
>> On Mar 8, 2012, at 6:48 PM, Sanne Grinovero wrote:
>>
>>> Hi,
>>> I found the same files in my workspace as left over from and older
>>> build, but deleted them and tried new builds several times, they don't
>>> seem to be re-created anymore?
>>> Could anyone confirm (after cleaning them up) that it's still a
>>> problem, as I can't..
>>>
>>> On the build issues, I had to rebuild and install locally
>>> infinispan-5.1.2.CR1 as it seems it couldn't find the test jars in
>>> Maven repositories.
>>
>> this also causes our master job fail
>>
>> Galder, how should we fix it?
>
> Abandon Gradle and move to Maven? ;)
>
> On a more serious note, I don't really know. Maybe the maven repository CI 
> uses is corrupt?
>
>>
>>>
>>> @Steve, regarding the upgrade of Infinispan in a minor release; is
>>> your concern the fact that it's not a Final version or is it about not
>>> changing any dependency version?
>>> As Infinispan 5.1.2.FINAL was released as well, so you could move forward.
>>>
>>> I had no other test failures.
>>>
>>> -- Sanne
>>>
>>> On 8 March 2012 10:34, Hardy Ferentschik  wrote:
 Hi,

 it just took 5 attempts to build everything :-(

 The first two times I got errors due to unresolved dependencies (first 
 time some docbook stuff, then Infinispan).
 In both cases the problem went away by restarting the build.

 The third time around I got a test failure in 
 org.hibernate.test.annotations.onetoone.OneToOneTest. No idea why.

 The forth time around 
 org.hibernate.envers.test.integration.components.PropertiesGroupTest 
 failed.
 I've seen this test fail before (also on the metamodel branch I believe). 
 Does anyone else see this test fail at times?

 The fifth time the build completed successfully. I can confirm that the 
 infinispan module creates some artifacts outside
 of the build directory ObjectStore and  PutObjectStoreDirHere. I don't 
 think the tests ran any slower than they used to.

 Total build time for me (according to gradle) was 11 mins 1.78 secs

 I find the "random" test errors worrying though. Anyone experiencing them 
 as well?

 --Hardy


 On Mar 8, 2012, at 3:56 AM, Steve Ebersole wrote:

> Hmm, I did not have problems resolving artifacts, but I just noticed
> this CR... we really need to not be upgrading to CR releases of
> dependencies as part of a point release.  Sigh
>
> On Wed 07 Mar 2012 08:19:55 PM CST, Strong Liu wrote:
>> btw ci fails due to
>>
>> 08:23:54.474 [ERROR] [org.gradle.BuildExceptionReporter] Could not
>> resolve all dependencies for configuration
>> ':hibernate-infinispan:testCompile'.
>> 08:23:54.478 [ERROR] [org.gradle.BuildExceptionReporter]>   Artifact 
>> 'org.infinispan:infinispan-core:5.1.2.CR1:tests@jar' not found.
>>
>> -
>> Best Regards,
>>
>> Strong Liuhttp://hibernate.org/>>
>> http://about.me/stliu/bio
>>
>> On Mar 8, 2012, at 10:04 AM, Steve Ebersole wrote:
>>
>>> Speaking of which, is everyone else seeing tests in
>>> hibernate-infinispan taking many many minutes to run?
>>
>>
>> yes, it reallly takes some time
>>
>>>
>>> On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
 Running the hibernate-infinispan tests I am seeing 2 output
 directories showing up in the hibernate-infinispan directory (aka, not
 hibernate-infinispan/target/...). Namely, I see
 hibernate-infinispan/ObjectStore and
 hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we can
 change where those directories get created?

>>>
>>> --
>>> st...@hibernate.org
>>> http://hibernate.org
>>> ___
>>> 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
 hibe

Re: [hibernate-dev] Hibernate ORM 4.1.1 release - Undocumented behavior change in Optimistic Versioning ?

[Demetz, Guenther]

Thank you Steve,

anyway in this context 
I strongly recommend all Hibernate-Users to force version increment explicitly 
on such OneToMany relations when the mapped collection is a map!
Otherwise, unless implementing some pessimistick locking, 2 concurrent 
transactions will be able to insert an object in the map, each indipendently 
from the other, using the same key value, without getting any exception at 
flush or commit time.
This leads finally in having 2 records persisted on database whilst in 
hibernate (due the constraints of the map) on successive accesses you always 
will see just one. This is quite dangereous.

regards
G.D.

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate OGM#OGM-123 Add Voldemort Datastore

[Seiya Kawashima]

Hi,

I've just found the task and was wondering if I can be assigned on this
task. I would like to finish the task based on the comments that I got and
will get for my pull request if it's possible.

-- 
Thank you
Seiya
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] testJGroupsBackend fail

[Sanne Grinovero]

Hi Nicolas,
I've improved that test to be less time-sensitive, could you checkout
latest master and give it another try please?

The warnings you see in the log are nothing to worry about, they are
related to the fact that the test is using an in-memory channel to
avoid trouble with your potentially wrong network configuration (it is
not actually sending data as UDP or TCP but looping it back in another
buffer as last element in the JGroups stack).

Sanne


On 5 March 2012 16:01, Nicolas Helleringer
 wrote:
> It fails here :
>
> at
> org.hibernate.search.test.jgroups.common.JGroupsCommonTest.testJGroupsBackend(JGroupsCommonTest.java:87
>
> Code seems pretty clear :
>
>  //get slave session
> Session s = getSlaveSession();
> Transaction tx = s.beginTransaction();
>  TShirt ts = new TShirt();
> ts.setLogo( "Boston" );
> ts.setSize( "XXL" );
>  ts.setLength( 23.4d );
> TShirt ts2 = new TShirt();
> ts2.setLogo( "Mapple leaves" );
>  ts2.setSize( "L" );
> ts2.setLength( 23.42d );
> s.persist( ts );
>  s.persist( ts2 );
> tx.commit();
>
> Thread.sleep( NETWORK_TIMEOUT );
>
> FullTextSession ftSess = Search.getFullTextSession( openSession() );
> ftSess.getTransaction().begin();
>  QueryParser parser = new QueryParser(
> TestConstants.getTargetLuceneVersion(), "id", TestConstants.stopAnalyzer );
> Query luceneQuery = parser.parse( "logo:Boston or logo:Mapple leaves" );
>  org.hibernate.Query query = ftSess.createFullTextQuery( luceneQuery );
> List result = query.list();
>
> assertEquals( 2, result.size() );
>
> Do not know why it is faling on my machine
>
> I got these in the output :
>
> 16:53:04,324 (main)  WARN NAKACK:292 - use_mcast_xmit should not be used
> because the transport (SHARED_LOOPBACK) does not support IP multicasting;
> setting use_mcast_xmit to false
>
> 16:53:04,973 (main)  WARN JGroupsBackendQueueProcessor:89 - HSEARCH07:
> FLUSH is not present in your JGroups stack!  FLUSH is needed to ensure
> messages are not dropped while new nodes join the cluster.  Will proceed,
> but inconsistencies may arise!
>
> 16:53:06,726 (Incoming-2,8de7f79c-777e-48cc-8901-c28398e3fb91,NC_NHE-23941)
>  WARN LuceneBackendQueueProcessor:101 - HSEARCH49: Was interrupted
> while waiting for index activity to finish. Index might be inconsistent or
> have a stale lock
>
> Hope it helps
>
> Niko
>
> 2012/3/5 Hardy Ferentschik 
>
>> Hi Niko,
>>
>> can you have a look at the reason for the failure? Is there something in
>> the test execution log?
>> It might just be a timing issue or maybe a multicast configuration problem
>> on windows.
>>
>> --Hardy
>>
>>
>> On Mar 5, 2012, at 4:14 PM, Nicolas Helleringer wrote:
>>
>> > On current master state I got a :
>> >
>> > Results :
>> >
>> > Failed tests:
>> >
>> >
>> testJGroupsBackend(org.hibernate.search.test.jgroups.common.JGroupsCommonTest):
>> > expected:<1> but was:<0>
>> >
>> > Tests run: 457, Failures: 1, Errors: 0, Skipped: 1
>> >
>> > I am on windows. Any ideas ?
>> >
>> > Cheers,
>> >
>> > Niko
>> > ___
>> > 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

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate OGM#OGM-123 Add Voldemort Datastore

[Emmanuel Bernard]

But you are already :)
If you mean physically on JIRA, send me your JIRA login.

Emmanuel

On 9 mars 2012, at 15:02, Seiya Kawashima wrote:

> Hi,
> 
> I've just found the task and was wondering if I can be assigned on this
> task. I would like to finish the task based on the comments that I got and
> will get for my pull request if it's possible.
> 
> -- 
> Thank you
> Seiya
> ___
> 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] Hibernate ORM 4.1.1 release - Undocumented behavior change in Optimistic Versioning ?

[Steve Ebersole]

Indexed collections (maps and lists) should always be the owning side 
of bi-directional associations for the exact reason you mention.  Not 
sure if annotations actually enforces that or whether JPA even allows 
us to enforce that.

On Fri 09 Mar 2012 07:53:20 AM CST, Demetz, Guenther wrote:
> Thank you Steve,
>
> anyway in this context
> I strongly recommend all Hibernate-Users to force version increment 
> explicitly on such OneToMany relations when the mapped collection is a map!
> Otherwise, unless implementing some pessimistick locking, 2 concurrent 
> transactions will be able to insert an object in the map, each indipendently 
> from the other, using the same key value, without getting any exception at 
> flush or commit time.
> This leads finally in having 2 records persisted on database whilst in 
> hibernate (due the constraints of the map) on successive accesses you always 
> will see just one. This is quite dangereous.
>
> regards
> G.D.

-- 
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] Hibernate ORM 4.1.1 release - Undocumented behavior change in Optimistic Versioning ?

[Demetz, Guenther]

>>Indexed collections (maps and lists) should always be the owning side of 
>>bi-directional associations for the exact reason you mention. 

OK, I suppose this is already mentioned somewhere in the documentation, or not 
? 

regards & nice weekend
G.D.



___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 4.1.1 release - Undocumented behavior change in Optimistic Versioning ?

[Steve Ebersole]

http://docs.jboss.org/hibernate/orm/3.5/reference/en-US/html_single/#collections-indexedbidirectional

Though:
1) Reading back through that section its not really clearly stated.
2) Later work to "fold in" the annotation mappings seems to have 
completely dropped this unclearly stated point.

Essentially what the section is trying to say is that if the child 
defines an attribute that is the map key (or list index) from the 
parent collection perspective, the collection can still be inverse 
(non-owning).  which totally makes sense, if you think it through.


On Fri 09 Mar 2012 08:44:28 AM CST, Demetz, Guenther wrote:
>
>>> Indexed collections (maps and lists) should always be the owning side of 
>>> bi-directional associations for the exact reason you mention.
>
> OK, I suppose this is already mentioned somewhere in the documentation, or 
> not ?
>
> regards&  nice weekend
> G.D.
>
>

-- 
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] testJGroupsBackend fail

[Nicolas Helleringer]

You roxx =)

I did build twice and it is working just nice.

Thanks a lot.

Niko

P.S : Ok ok I'll buy a MacBookPro with a SSD ... or not !

2012/3/9 Sanne Grinovero 

> Hi Nicolas,
> I've improved that test to be less time-sensitive, could you checkout
> latest master and give it another try please?
>
> The warnings you see in the log are nothing to worry about, they are
> related to the fact that the test is using an in-memory channel to
> avoid trouble with your potentially wrong network configuration (it is
> not actually sending data as UDP or TCP but looping it back in another
> buffer as last element in the JGroups stack).
>
> Sanne
>
>
> On 5 March 2012 16:01, Nicolas Helleringer
>  wrote:
> > It fails here :
> >
> > at
> >
> org.hibernate.search.test.jgroups.common.JGroupsCommonTest.testJGroupsBackend(JGroupsCommonTest.java:87
> >
> > Code seems pretty clear :
> >
> >  //get slave session
> > Session s = getSlaveSession();
> > Transaction tx = s.beginTransaction();
> >  TShirt ts = new TShirt();
> > ts.setLogo( "Boston" );
> > ts.setSize( "XXL" );
> >  ts.setLength( 23.4d );
> > TShirt ts2 = new TShirt();
> > ts2.setLogo( "Mapple leaves" );
> >  ts2.setSize( "L" );
> > ts2.setLength( 23.42d );
> > s.persist( ts );
> >  s.persist( ts2 );
> > tx.commit();
> >
> > Thread.sleep( NETWORK_TIMEOUT );
> >
> > FullTextSession ftSess = Search.getFullTextSession( openSession() );
> > ftSess.getTransaction().begin();
> >  QueryParser parser = new QueryParser(
> > TestConstants.getTargetLuceneVersion(), "id", TestConstants.stopAnalyzer
> );
> > Query luceneQuery = parser.parse( "logo:Boston or logo:Mapple leaves" );
> >  org.hibernate.Query query = ftSess.createFullTextQuery( luceneQuery );
> > List result = query.list();
> >
> > assertEquals( 2, result.size() );
> >
> > Do not know why it is faling on my machine
> >
> > I got these in the output :
> >
> > 16:53:04,324 (main)  WARN NAKACK:292 - use_mcast_xmit should not be used
> > because the transport (SHARED_LOOPBACK) does not support IP multicasting;
> > setting use_mcast_xmit to false
> >
> > 16:53:04,973 (main)  WARN JGroupsBackendQueueProcessor:89 -
> HSEARCH07:
> > FLUSH is not present in your JGroups stack!  FLUSH is needed to ensure
> > messages are not dropped while new nodes join the cluster.  Will proceed,
> > but inconsistencies may arise!
> >
> > 16:53:06,726
> (Incoming-2,8de7f79c-777e-48cc-8901-c28398e3fb91,NC_NHE-23941)
> >  WARN LuceneBackendQueueProcessor:101 - HSEARCH49: Was interrupted
> > while waiting for index activity to finish. Index might be inconsistent
> or
> > have a stale lock
> >
> > Hope it helps
> >
> > Niko
> >
> > 2012/3/5 Hardy Ferentschik 
> >
> >> Hi Niko,
> >>
> >> can you have a look at the reason for the failure? Is there something in
> >> the test execution log?
> >> It might just be a timing issue or maybe a multicast configuration
> problem
> >> on windows.
> >>
> >> --Hardy
> >>
> >>
> >> On Mar 5, 2012, at 4:14 PM, Nicolas Helleringer wrote:
> >>
> >> > On current master state I got a :
> >> >
> >> > Results :
> >> >
> >> > Failed tests:
> >> >
> >> >
> >>
> testJGroupsBackend(org.hibernate.search.test.jgroups.common.JGroupsCommonTest):
> >> > expected:<1> but was:<0>
> >> >
> >> > Tests run: 457, Failures: 1, Errors: 0, Skipped: 1
> >> >
> >> > I am on windows. Any ideas ?
> >> >
> >> > Cheers,
> >> >
> >> > Niko
> >> > ___
> >> > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan tests

[Steve Ebersole]

Yaay!  It ony took slightly over 5 minutes today.  But of course:

> Building > :hibernate-infinispan:test > Resolving dependencies 
> ':hibernate-infinispan:test:hibernate-infinispan:test
Test 
org.hibernate.test.cache.infinispan.entity.InvalidatedTransactionalTestCase 
FAILED
Test org.hibernate.test.cache.infinispan.entity.ReadOnlyTestCase FAILED
101 tests completed, 19 failures

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':hibernate-infinispan:test'.
> There were failing tests. See the report at 
> /home/steve/projects/hibernate/4/hibernate-orm/hibernate-infinispan/target/reports/tests.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or 
--debug option to get more log output.

BUILD FAILED

Total time: 5 mins 6.757 secs


On Fri 09 Mar 2012 06:25:42 AM CST, Steve Ebersole wrote:
> Luckily you get to decide to follow the company line and use inferior 
> tools as part of your project.
>
> Considering that part works everywhere I find it funny that you can 
> chalk my issue up to env but this has to be a "gradle/ivy bug" lol.
>
> There is also a far easier syntax for how you are trying to pull in 
> infinispan artifacts. I'll work on updating that for you.
>
> As for my "env issues", such as? I'd really like my build to finish in 
> less than an hour! :)
>
>
> On Fri 09 Mar 2012 03:51:45 AM CST, Galder Zamarreño wrote:
>>
>> On Mar 8, 2012, at 4:46 PM, Strong Liu wrote:
>>
>>>
>>> On Mar 8, 2012, at 6:48 PM, Sanne Grinovero wrote:
>>>
 Hi,
 I found the same files in my workspace as left over from and older
 build, but deleted them and tried new builds several times, they don't
 seem to be re-created anymore?
 Could anyone confirm (after cleaning them up) that it's still a
 problem, as I can't..

 On the build issues, I had to rebuild and install locally
 infinispan-5.1.2.CR1 as it seems it couldn't find the test jars in
 Maven repositories.
>>>
>>> this also causes our master job fail
>>>
>>> Galder, how should we fix it?
>>
>> Abandon Gradle and move to Maven? ;)
>>
>> On a more serious note, I don't really know. Maybe the maven 
>> repository CI uses is corrupt?
>>
>>>

 @Steve, regarding the upgrade of Infinispan in a minor release; is
 your concern the fact that it's not a Final version or is it about not
 changing any dependency version?
 As Infinispan 5.1.2.FINAL was released as well, so you could move 
 forward.

 I had no other test failures.

 -- Sanne

 On 8 March 2012 10:34, Hardy Ferentschik wrote:
> Hi,
>
> it just took 5 attempts to build everything :-(
>
> The first two times I got errors due to unresolved dependencies 
> (first time some docbook stuff, then Infinispan).
> In both cases the problem went away by restarting the build.
>
> The third time around I got a test failure in 
> org.hibernate.test.annotations.onetoone.OneToOneTest. No idea why.
>
> The forth time around 
> org.hibernate.envers.test.integration.components.PropertiesGroupTest 
> failed.
> I've seen this test fail before (also on the metamodel branch I 
> believe). Does anyone else see this test fail at times?
>
> The fifth time the build completed successfully. I can confirm 
> that the infinispan module creates some artifacts outside
> of the build directory ObjectStore and PutObjectStoreDirHere. I 
> don't think the tests ran any slower than they used to.
>
> Total build time for me (according to gradle) was 11 mins 1.78 secs
>
> I find the "random" test errors worrying though. Anyone 
> experiencing them as well?
>
> --Hardy
>
>
> On Mar 8, 2012, at 3:56 AM, Steve Ebersole wrote:
>
>> Hmm, I did not have problems resolving artifacts, but I just noticed
>> this CR... we really need to not be upgrading to CR releases of
>> dependencies as part of a point release. Sigh
>>
>> On Wed 07 Mar 2012 08:19:55 PM CST, Strong Liu wrote:
>>> btw ci fails due to
>>>
>>> 08:23:54.474 [ERROR] [org.gradle.BuildExceptionReporter] Could not
>>> resolve all dependencies for configuration
>>> ':hibernate-infinispan:testCompile'.
>>> 08:23:54.478 [ERROR] [org.gradle.BuildExceptionReporter]> 
>>> Artifact 'org.infinispan:infinispan-core:5.1.2.CR1:tests@jar' 
>>> not found.
>>>
>>> -
>>> Best Regards,
>>>
>>> Strong Liuhttp://hibernate.org/>>
>>> http://about.me/stliu/bio
>>>
>>> On Mar 8, 2012, at 10:04 AM, Steve Ebersole wrote:
>>>
 Speaking of which, is everyone else seeing tests in
 hibernate-infinispan taking many many minutes to run?
>>>
>>>
>>> yes, it reallly takes some time
>>>

 On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
> Running the hibernate-infinispan tests I am se

Re: [hibernate-dev] immutable can be deleted? and should readonly cache throw exception?

[Gail Badner]

The documentation in 12.1.1 is correct. Read-only entities can be created and 
deleted.

Sounds like you can't delete a single entity from the 2nd-level cache though. 
That sounds like a bug.

- Original Message -
> From: "Steve Ebersole" 
> To: "Strong Liu" 
> Cc: "Hibernate hibernate-dev" 
> Sent: Friday, March 9, 2012 4:16:16 AM
> Subject: Re: [hibernate-dev] immutable can be deleted? and should readonly 
> cache throw exception?
> 
> 
> Immutable entities should still be deletable.  Unless Gail changed
> that
> during the consolidation with making a particular entity instance
> "read
> only" as part of a session.  There was a lot of discussion at that
> time
> wrt consistency between these two things.  I forget all the outcomes.
> But immutable used to mean it could still be deleted.
> 
> HQL bulk deletes and updates circumvent normal modes of operation at
> many levels, caching being one of them.  It interacts with the cache
> in
> a much different way than a normal Session.delete.
> 
> Marking an entity with a cache access strategy of read-only is a bit
> different semantic.
> 
> +1000 about test method independence.  This has bitten us over and
> over
> again.
> 
> On Fri 09 Mar 2012 01:24:57 AM CST, Strong Liu wrote:
> > Hi There,
> >
> > is an immutable entity can be deleted?
> >
> > according to
> > http://docs.jboss.org/hibernate/core/4.0/manual/en-US/html_single/
> >
> > "12.1.1. Entities of immutable classes"
> >
> > "An entity of an immutable class can created and deleted the same
> > as an entity of a mutable class."
> >
> > but "5.1.1 Entity" saying:
> >
> > "Some entities are not mutable. They cannot be updated or deleted
> > by the application. This allows Hibernate to make some minor
> > performance optimizations.. Use the @Immutable annotation."
> >
> > the reason i'm asking this is this test
> > org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest#testPolymorphism.
> >
> > when running testsuite on jdk 7, the order of methods returned by
> > getDeclaredMethods changed and can vary from run to run
> > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7023180), so,
> > the order of each test case in a test class can't be guaranteed.
> >
> > so, we need each test case independent.
> >
> > clearly, this test case depends on the order.
> >
> > I added a cleanupTest method
> >
> > @Override
> > protected void cleanupTest() throws Exception {
> > Session s = openSession();
> > s.beginTransaction();
> > List list = s.createQuery( "from java.lang.Object" ).list();
> > for(Object obj :  list){
> > s.delete( obj );
> > }
> > s.getTransaction().commit();
> > s.close();
> > }
> >
> > and get this exception:
> >
> > java.lang.UnsupportedOperationException: Can't write to a readonly
> > object
> > at
> > 
> > org.hibernate.testing.cache.ReadOnlyEntityRegionAccessStrategy.lockItem(ReadOnlyEntityRegionAccessStrategy.java:68)
> > at
> > 
> > org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:84)
> > at
> > org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
> > at
> > 
> > org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
> > at
> > 
> > org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:280)
> > at
> > 
> > org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
> > at
> > 
> > org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
> > at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127)
> > at
> > org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:325)
> > at
> > 
> > org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101)
> > at
> > 
> > org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
> > at
> > 
> > org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest.cleanupTest(BasicHibernateAnnotationsTest.java:105)
> > 
> >
> > btw, i'm also seeing this jira
> > https://hibernate.onjira.com/browse/HHH-6329
> >
> > change the cleanupTest to use hql (s.createQuery("delete
> > java.lang.Object").executeUpdate();) runs successfully and no test
> > failure.
> >
> > -
> > Best Regards,u
> >
> > Strong Liu
> > http://about.me/stliu/bio
> >
> > ___
> > 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