You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2012/01/05 15:16:16 UTC
Newbie questions
Hello,
we are tying to migrate our Open Source Identity Management system
Syncope [1] from Hibernate because we are willing to apply for entering
ASF incubator [2].
I was using OpenJPA 2.1.1 but I found an issue with @OneToMany and some
null collections so, after reading [3] I switched to 2.2.0-SNAPSHOT and
this issue disappeared.
Unfortunately I am now facing few issues:
1. some (harmless?) warnings like as (this because I was using query
hints with Hibernate, for 2nd level caching):
137309 syncopePersistenceUnit WARN [http-bio-9080-exec-3]
openjpa.Runtime - "javax.persistence.cache.retrieveMode" is not a
supported query hint. May be you meant "javax.persistence.lock.timeout"?
137310 syncopePersistenceUnit WARN [http-bio-9080-exec-3]
openjpa.Runtime - "javax.persistence.cache.storeMode" is not a supported
query hint. May be you meant "javax.persistence.lock.timeout"?
2. blocking errors like as:
<openjpa-2.2.0-SNAPSHOT-r422266:1226933 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: Cannot load object
with id "1006". Instance
"org.syncope.core.persistence.beans.SchemaMapping@39be9f72" with the
same id already exists in the L1 cache. This can occur when you assign
an existing id to a new instance, and before flushing attempt to load
the existing instance for that id.
I guess that this happen because at some stage an entity A (in
@OneToMany relation with another entity B) is read, then afterwards a
"SELECT e FROM B" is issued, in the same transaction. How can I fix this?
Moreover, is there any planned date for release 2.2.0?
TIA.
Regards.
[1] http://www.syncope-idm.org
[2] https://wiki.apache.org/incubator/SyncopeProposal
[3]
http://openjpa.208410.n2.nabble.com/Should-OpenJPA-initialise-empty-collections-td6926980.html
--
Francesco Chicchiriccò
Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/
Re: Newbie questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 05/01/2012 16:20, Kevin Sutter wrote:
> Welcome, Francesco, to the Apache and OpenJPA usage!
Thanks! I am quite used to ASF, but in other contexts (like as Cocoon or
Wicket), so OpenJPA is a complete new world for me :-)
> I hope we can get you by your hiccups very soon...
>
> 2012/1/5 Francesco Chicchiriccò <il...@apache.org>
>
>> I was using OpenJPA 2.1.1 but I found an issue with @OneToMany and some
>> null collections so, after reading [3] I switched to 2.2.0-SNAPSHOT and
>> this issue disappeared.
> Sounds good. Since it's easy for you to move up to a newer level, that's the right way to go.
>
>> Unfortunately I am now facing few issues:
> Are these issues new since moving to OpenJPA 2.2.0? Or, are you now
> experiencing them due to making more progress with OpenJPA 2.2..0? I don't
> see these as being unique to 2.2.0, but I just want to clarify.
I had issue 1 with 2.1.1 as well; issue 2 appeared when I switched to
2.2.0-SNAPSHOT.
>> 1. some (harmless?) warnings like as (this because I was using query
>> hints with Hibernate, for 2nd level caching):
>>
>> 137309 syncopePersistenceUnit WARN [http-bio-9080-exec-3]
>> openjpa.Runtime - "javax.persistence.cache.retrieveMode" is not a
>> supported query hint. May be you meant "javax.persistence.lock.timeout"?
>> 137310 syncopePersistenceUnit WARN [http-bio-9080-exec-3]
>> openjpa.Runtime - "javax.persistence.cache.storeMode" is not a supported
>> query hint. May be you meant "javax.persistence.lock.timeout"?
>>
> So, Hibernate is supporting these properties as query hints? Per the spec,
> we support these properties as "true" properties in persistence.xml. But,
> we currently do not support these properties as query hints.
Does this mean - as I understand - that these properties are applied to
ALL queries?
>> 2. blocking errors like as:
>>
>> <openjpa-2.2.0-SNAPSHOT-r422266:1226933 nonfatal user error>
>> org.apache.openjpa.persistence.ArgumentException: Cannot load object
>> with id "1006". Instance
>> "org.syncope.core.persistence.beans.SchemaMapping@39be9f72" with the
>> same id already exists in the L1 cache. This can occur when you assign
>> an existing id to a new instance, and before flushing attempt to load
>> the existing instance for that id.
>>
>> I guess that this happen because at some stage an entity A (in
>> @OneToMany relation with another entity B) is read, then afterwards a
>> "SELECT e FROM B" is issued, in the same transaction. How can I fix this?
> Simple queries you like describe should not create the issue you describe.
> The common scenario is as the message text describes. For example, is it
> possible that you have created a new instance of Entity B with an existing
> id value? Then, you attempt to load the existing Entity from the database?
> That's the common scenario. You may be hitting something else, but I'd
> take a look at that scenario first.
For the sake of completeness, I am running with Spring 3's @Transactional.
Issue arises in a test method.
>From my first example, ExternalResource is A and SchemaMapping is B;
resourceDAO.findAllMappings() does the "SELECT e FROM SchemaMapping e".
ExternalResource csv = resourceDAO.find("resource-csv");
SchemaMapping newMapping = new SchemaMapping();
newMapping.setIntMappingType(IntMappingType.Username);
newMapping.setExtAttrName("TEST");
newMapping.setResource(csv);
csv.addMapping(newMapping);
resourceDAO.merge(csv);
resourceDAO.flush();
List<SchemaMapping> allMappings = resourceDAO.findAllMappings();
If I put a "entityManager.clear())" right before the
resourceDAO.findAllMappings(), the test succeeds, of course.
I guess that the problem is related to the fact that a SchemaMapping
instance is eagerly loaded into the persistence context when
entityManager.merge() on ExternalResource happens. When, afterwards,
resourceDAO.findAllMappings() attempts to load all defined
SchemaMappings, there is a conflicting SchemaMapping in the persistence
context.
If this is correct my question is: how can I configure things so that
subsequent query overwrites existing instances?
>> Moreover, is there any planned date for release 2.2.0?
> We just started a [DISCUSS] message thread on this exact topic this week.
> Follow that thread to see what we come up with. My guess is that we'll
> turn this around quickly (ie. within a month or so).
This sounds very good!
Regards.
> [1] http://www.syncope-idm.org
> [2] https://wiki.apache.org/incubator/SyncopeProposal
> [3] http://openjpa.208410.n2.nabble.com/Should-OpenJPA-initialise-empty-collections-td6926980.html
--
Francesco Chicchiriccò
Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/
Re: Newbie questions
Posted by Kevin Sutter <kw...@gmail.com>.
Welcome, Francesco, to the Apache and OpenJPA usage! I hope we can get you
by your hiccups very soon...
2012/1/5 Francesco Chicchiriccò <il...@apache.org>
>
> I was using OpenJPA 2.1.1 but I found an issue with @OneToMany and some
> null collections so, after reading [3] I switched to 2.2.0-SNAPSHOT and
> this issue disappeared.
>
Sounds good. Since it's easy for you to move up to a newer level, that's
the right way to go.
>
> Unfortunately I am now facing few issues:
>
Are these issues new since moving to OpenJPA 2.2.0? Or, are you now
experiencing them due to making more progress with OpenJPA 2.2..0? I don't
see these as being unique to 2.2.0, but I just want to clarify.
>
> 1. some (harmless?) warnings like as (this because I was using query
> hints with Hibernate, for 2nd level caching):
>
> 137309 syncopePersistenceUnit WARN [http-bio-9080-exec-3]
> openjpa.Runtime - "javax.persistence.cache.retrieveMode" is not a
> supported query hint. May be you meant "javax.persistence.lock.timeout"?
> 137310 syncopePersistenceUnit WARN [http-bio-9080-exec-3]
> openjpa.Runtime - "javax.persistence.cache.storeMode" is not a supported
> query hint. May be you meant "javax.persistence.lock.timeout"?
>
So, Hibernate is supporting these properties as query hints? Per the spec,
we support these properties as "true" properties in persistence.xml. But,
we currently do not support these properties as query hints.
> 2. blocking errors like as:
>
> <openjpa-2.2.0-SNAPSHOT-r422266:1226933 nonfatal user error>
> org.apache.openjpa.persistence.ArgumentException: Cannot load object
> with id "1006". Instance
> "org.syncope.core.persistence.beans.SchemaMapping@39be9f72" with the
> same id already exists in the L1 cache. This can occur when you assign
> an existing id to a new instance, and before flushing attempt to load
> the existing instance for that id.
>
> I guess that this happen because at some stage an entity A (in
> @OneToMany relation with another entity B) is read, then afterwards a
> "SELECT e FROM B" is issued, in the same transaction. How can I fix this?
>
Simple queries you like describe should not create the issue you describe.
The common scenario is as the message text describes. For example, is it
possible that you have created a new instance of Entity B with an existing
id value? Then, you attempt to load the existing Entity from the database?
That's the common scenario. You may be hitting something else, but I'd
take a look at that scenario first.
> Moreover, is there any planned date for release 2.2.0?
>
We just started a [DISCUSS] message thread on this exact topic this week.
Follow that thread to see what we come up with. My guess is that we'll
turn this around quickly (ie. within a month or so).
Good luck with the migration.
Kevin
>
> TIA.
> Regards.
>
> [1] http://www.syncope-idm.org
> [2] https://wiki.apache.org/incubator/SyncopeProposal
> [3]
>
> http://openjpa.208410.n2.nabble.com/Should-OpenJPA-initialise-empty-collections-td6926980.html
>
>
> --
> Francesco Chicchiriccò
>
> Apache Cocoon Committer and PMC Member
> http://people.apache.org/~ilgrosso/
>
>