openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <>
Subject Re: Newbie questions
Date Thu, 05 Jan 2012 15:20:49 GMT
Welcome, Francesco, to the Apache and OpenJPA usage!  I hope we can get you
by your hiccups very soon...

2012/1/5 Francesco Chicchiriccò <>

> 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.

> TIA.
> Regards.
> [1]
> [2]
> [3]
> --
> Francesco Chicchiriccò
> Apache Cocoon Committer and PMC Member

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message