Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of kwsutter@gmail.com designates
 209.85.215.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <88CB62524DE0644AAE21D8BAB8CFC0CA01A2B025@dueexs06.bertschi.domain>
References: 
 <88CB62524DE0644AAE21D8BAB8CFC0CA01A2B025@dueexs06.bertschi.domain>
From: Kevin Sutter <kwsutter@gmail.com>
Date: Thu, 7 Jun 2012 13:47:40 -0500
Message-ID: 
 <CABH8ernt5ygikyMhmTuK5eo37q0dQU1TQ5y+54Ynm-mFTN0yyw@mail.gmail.com>
Subject: Re: Bug? DataCache after update contains only the updated information
 from a Collection
To: users@openjpa.apache.org
Content-Type: multipart/alternative; boundary=f46d04083adbadff8404c1e652cc

--f46d04083adbadff8404c1e652cc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi John,
Good background information.  Thanks for the detail.  Unfortunately,
nothing is jumping out at me as an "easy fix".  I do have a couple of
observations and/or questions...

o  Why is the @InverseLogical annotation required?  It would seem that you
have already defined the bidirectional relationship via the mappedBy
attribute on the @OneToMany.  Is there something else you were trying to
model by using the @InverseLogical?  And, does the removal of that
annotation change the processing in any way?

o  Can you explain the use of the update() method?  Are the entities being
passed into this method detached from a persistence context?  That's where
the merge() method comes into play -- merging detached entities into a
persistence context.  The merge() method is not used just because there are
updates to an Entity.

o  Your code example doesn't show the actual interaction with the EM.  How
is the lifecycle of the EM being managed, and is the same EM being used for
all of the interactions with transactions, persisting, merging, etc?

o  Can you post your whole persistence.xml?  For example, you didn't
mention the use of the QueryCache property, but it looks like this is
enabled via the dump of the properties.  The QueryCache is no longer
automatically enabled when the DataCache is enabled, so it must be
explicitly enabled.  Not that it should affect this particular scenario,
but I'm just curious if there are other property "mismatches" that I didn't
catch.

o  If none of these questions provide any fruit, then you might have found
a bug and a JIRA will be required.  But, let's do a bit more Q&A first...

Thanks,
Kevin

On Thu, Jun 7, 2012 at 2:05 AM, Boblitz John <John.Boblitz@bertschi.com>wro=
te:

> Hello,
>
> I'm running openJpa 2.2.0 and have a problem with the DataCache function.
> I spent the better part of two days localizing the problem and looking fo=
r
> solutions, but alas ...
>
> So, hoping some guru out there can spot my error, here the details:
>
> Environment JavaSE
>
> Persistence XML:
> <property name=3D"openjpa.DataCache" value=3D"true(CacheSize=3D5000,
> EnableStatistics=3Dtrue)" />
> <property name=3D"openjpa.RemoteCommitProvider" value=3D"sjvm" />
> <property name=3D"openjpa.DetachState"
> value=3D"fetch-groups(DetachedStateField=3Dtrue)" />
>
> Entities:
>
> @MappedSuperclass
> @EntityListeners({ EntityManipulationLogger.class, EntityLogger.class })
> public abstract class BaseEntity {
> @Version
> @Column(columnDefinition =3D "int8")
> private long versionId;
>
> @Id
> @GeneratedValue(strategy =3D GenerationType.SEQUENCE)
> @Column(name =3D "uniqueid", columnDefinition =3D "int8")
> protected long uniqueId;
>
> ...
>
> @Entity
> @Table(name =3D "Equipment")
> public class Equipment extends BaseEntity {
>
> @JsonManagedReference
> @OneToMany(cascade =3D CascadeType.ALL, mappedBy =3D "equipmentId")
> @InverseLogical("equipmentId")
> private Set<Axle> axles =3D new HashSet<Axle>();
>
> ...
>
> @Entity
> @Table(name =3D "Axle")
> public class Axle extends BaseEntity {
>
> @JsonBackReference
> @ManyToOne(fetch =3D FetchType.EAGER)
> @JoinColumn(name =3D "equipmentId", columnDefinition =3D "int8", nullable=
 =3D
> false)
> private Equipment equipmentId;
>
>
> Code used to Update the DataBase:
>
> @Override
> public <T extends BaseEntity> T update(T pEntity) {
>    this.lock.lock();
>   T object =3D null;
>    try {
>         try {
>                getTransaction().begin();
>                object =3D merge(pEntity);
>        } catch (Exception e) {
>                mTrc.error("Error in update(): ", e);
>                getTransaction().setRollbackOnly();
>                handleException(e);
>        } finally {
>                if (getTransaction().isActive()) {
>                    if (getTransaction().getRollbackOnly()) {
>                    getTransaction().rollback();
>                } else {
>                    getTransaction().commit();
>                }
>            }
>        }
>    } catch (Exception e) {
>        mTrc.error("Error in update(): ", e);
>        handleException(e);
>    } finally {
>        this.lock.unlock();
>    }
>    return object;
> }
>
> Symptom:
> When updating the Equipment entity, if an additional Axle is added to the
> Set and the other Axles remain unchanged:
> 1.  Upon entry into update(), pEntity contains all the Axels (new & old)
> including UID & Version.
> 2.  object =3D merge(pEntity) - performs as expected, object contains all
> the Axels and the new Axel has been assigned a UID
> 3.  After commit(), the new Axle is added to the Database (good)
> 4.  The entity is updated in the DataCache (I would assume this is good a=
s
> well)
> 5.  "object" however now only contains one element in the Set<Axle> - the
> one we added, the others are no longer there.
> 6.  A subsequent refresh of the returns the same results as in #5! It hit=
s
> in the DataCache, so I assume that the Update of the Cache
> contains only the "new" data from object.
>
> Turning off the DataCache (or excluding the Equipment Entity) solves the
> problem.
>
> Here the complete config:
>
> openjpa.AutoClear: 0
> openjpa.AutoDetach: [Ljava.lang.String;@60cf710e
> openjpa.BrokerFactory: jdbc
> openjpa.BrokerImpl: default
> openjpa.CacheDistributionPolicy: default
> openjpa.Callbacks: default
> openjpa.ClassResolver: default
> openjpa.Compatibility: default
> openjpa.ConnectionDriverName: org.postgresql.Driver
> openjpa.ConnectionFactoryMode: false
> openjpa.ConnectionFactoryProperties: QueryTimeOut=3D5000, PrettyPrint=3Dt=
rue,
> PrettyPrintLineLength=3D80, PrintParameters=3Dtrue
> openjpa.ConnectionPassword: ******
> openjpa.ConnectionProperties: MaxActive=3D100, MaxIdle=3D5, MinIdle=3D2,
> MaxWait=3D60000
> openjpa.ConnectionRetainMode: 0
> openjpa.ConnectionURL: ******
> openjpa.ConnectionUserName: *****
> openjpa.DataCache: true(CacheSize=3D5000, EnableStatistics=3Dtrue)
> openjpa.DataCacheManager: default
> openjpa.DataCacheTimeout: -1
> openjpa.DetachState: fgs(DetachedStateField=3Dtrue)
> openjpa.DynamicDataStructs: false
> openjpa.DynamicEnhancementAgent: true
> openjpa.EntityManagerFactory: default
> openjpa.FetchBatchSize: -1
> openjpa.FetchGroups: [Ljava.lang.String;@53077fc9
> openjpa.FlushBeforeQueries: 0
> openjpa.Id: g11.persistence
> openjpa.IgnoreChanges: false
> openjpa.InitializeEagerly: false
> openjpa.InstrumentationManager: default
> openjpa.InverseManager: true
> openjpa.LifecycleEventManager: validating
> openjpa.LockManager: mixed
> openjpa.Log: log4j
> openjpa.ManagedRuntime: auto
> openjpa.MaxFetchDepth: -1
> openjpa.MetaDataFactory: *** truncated!!
> openjpa.MetaDataRepository: default
> openjpa.Multithreaded: false
> openjpa.NontransactionalRead: true
> openjpa.NontransactionalWrite: true
> openjpa.Optimistic: true
> openjpa.OrphanedKeyAction: log
> openjpa.ProxyManager: default
> openjpa.QueryCache: true(CacheSize=3D1000, SoftReferenceSize=3D100,
> EvictPolicy=3D'timestamp')
> openjpa.QueryCompilationCache: all
> openjpa.ReadLockLevel: 10
> openjpa.RefreshFromDataCache: false
> openjpa.RemoteCommitProvider: sjvm
> openjpa.RestoreState: 1
> openjpa.RetainState: true
> openjpa.RetryClassRegistration: false
> openjpa.RuntimeUnenhancedClasses: 1
> openjpa.SavepointManager: in-mem
> openjpa.Sequence: table
> openjpa.TransactionMode: false
> openjpa.WriteLockLevel: 20
> openjpa.jdbc.DBDictionary:
> postgres(supportsNullTableForGetImportedKeys=3Dfalse)
> openjpa.jdbc.DriverDataSource: auto
> openjpa.jdbc.EagerFetchMode: 2
> openjpa.jdbc.FetchDirection: 1000
> openjpa.jdbc.FinderCache: true
> openjpa.jdbc.IdentifierUtil: default
> openjpa.jdbc.LRSSize: 2
> openjpa.jdbc.MappingDefaults: jpa
> openjpa.jdbc.QuerySQLCache: true(EnableStatistics=3Dtrue)
> openjpa.jdbc.ResultSetType: 1003
> openjpa.jdbc.SQLFactory: default
> openjpa.jdbc.SchemaFactory: native(ForeignKeys=3Dtrue)
> openjpa.jdbc.Schemas: [Ljava.lang.String;@60cf710e
> openjpa.jdbc.SubclassFetchMode: 1
> openjpa.jdbc.SynchronizeMappings: null
> openjpa.jdbc.TransactionIsolation: -1
> openjpa.jdbc.UpdateManager: default
>
>
>
>
>
> =EF=BB=BF
>
> John
>
> ----
>
> Who is General Failure, and why is he reading my hard disk?
>
>

--f46d04083adbadff8404c1e652cc--