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ò <ilgro...@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/
