openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: Newbie questions
Date Thu, 05 Jan 2012 15:41:20 GMT
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ò <ilgrosso@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/


Mime
View raw message