cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: optimistic locking exception due to locking on not "Used For Locking" null to-one relationship
Date Wed, 18 Sep 2013 17:27:24 GMT
After closing the modeler, doc, and tutorial projects, I am left with
these unresolved errors:

Description    Resource    Path    Location    Type
Plugin execution not covered by lifecycle configuration:
org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date
(execution: date, phase: initialize)    pom.xml
/cayenne-jdk1.6-unpublished    line 78    Maven Project Build
Lifecycle Mapping Problem
Plugin execution not covered by lifecycle configuration:
org.apache.maven.plugins:maven-remote-resources-plugin:1.4:bundle
(execution: default, phase: generate-resources)    pom.xml
/cayenne-legal-unpublished    line 65    Maven Project Build Lifecycle
Mapping Problem
Plugin execution not covered by lifecycle configuration:
org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date
(execution: date, phase: initialize)    pom.xml
/cayenne-legal-unpublished    line 53    Maven Project Build Lifecycle
Mapping Problem
Plugin execution not covered by lifecycle configuration:
org.objectstyle.woproject.maven2:maven-japplication-plugin:2.0.17:japplication
(execution: default, phase: generate-resources)    pom.xml
/cayenne-modeler-java    line 77    Maven Project Build Lifecycle
Mapping Problem
Plugin execution not covered by lifecycle configuration:
org.apache.maven.plugins:maven-antrun-plugin:1.3:run (execution:
default, phase: process-sources)    pom.xml
/cayenne-jdk1.5-unpublished    line 214    Maven Project Build
Lifecycle Mapping Problem
Plugin execution not covered by lifecycle configuration:
org.codehaus.mojo:javacc-maven-plugin:2.5:javacc (execution:
javacc-ejbql, phase: generate-sources)    pom.xml
/cayenne-jdk1.5-unpublished    line 172    Maven Project Build
Lifecycle Mapping Problem
Plugin execution not covered by lifecycle configuration:
org.codehaus.mojo:javacc-maven-plugin:2.5:jjtree (execution:
jjtree-ejbql, phase: generate-sources)    pom.xml
/cayenne-jdk1.5-unpublished    line 156    Maven Project Build
Lifecycle Mapping Problem
Plugin execution not covered by lifecycle configuration:
org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date
(execution: date, phase: initialize)    pom.xml
/cayenne-jdk1.5-unpublished    line 263    Maven Project Build
Lifecycle Mapping Problem



On Wed, Sep 18, 2013 at 1:25 PM, Mike Kienenberger <mkienenb@gmail.com> wrote:
> All 2100+ tests for my own project now pass under my modified 3.0.2.
>
> However, I'm having problems getting a STABLE-3.0 development
> environment set up under Eclipse so that I can investigate the failing
> cayenne tests.
>
> I tried following the directions under
> http://cayenne.apache.org/dev/eclipse.html using Eclipse Version: Juno
> Release Build id: 20120614-1722 but after the process created 37
> projects in the workspace, I'm still left with 243 java compile errors
> and 13 maven problems.
>
> The java errors seem like tutorial or modeler errors which I can
> probably ignore. (like no com.apple imports).
>
> I'm not sure what to make of the maven errors as some of these are in
> primary modules.
>
> Description    Resource    Path    Location    Type
> Plugin execution not covered by lifecycle configuration:
> org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date
> (execution: date, phase: initialize)    pom.xml
> /cayenne-jdk1.6-unpublished    line 78    Maven Project Build
> Lifecycle Mapping Problem
> Plugin execution not covered by lifecycle configuration:
> org.apache.maven.plugins:maven-remote-resources-plugin:1.4:bundle
> (execution: default, phase: generate-resources)    pom.xml
> /cayenne-legal-unpublished    line 65    Maven Project Build Lifecycle
> Mapping Problem
> Plugin execution not covered by lifecycle configuration:
> org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date
> (execution: date, phase: initialize)    pom.xml
> /cayenne-legal-unpublished    line 53    Maven Project Build Lifecycle
> Mapping Problem
> Plugin execution not covered by lifecycle configuration:
> org.objectstyle.woproject.maven2:maven-japplication-plugin:2.0.17:japplication
> (execution: default, phase: generate-resources)    pom.xml
> /cayenne-modeler-java    line 77    Maven Project Build Lifecycle
> Mapping Problem
> Plugin execution not covered by lifecycle configuration:
> org.apache.maven.plugins:maven-antrun-plugin:1.3:run (execution:
> default, phase: process-sources)    pom.xml
> /cayenne-jdk1.5-unpublished    line 214    Maven Project Build
> Lifecycle Mapping Problem
> Plugin execution not covered by lifecycle configuration:
> org.codehaus.mojo:javacc-maven-plugin:2.5:javacc (execution:
> javacc-ejbql, phase: generate-sources)    pom.xml
> /cayenne-jdk1.5-unpublished    line 172    Maven Project Build
> Lifecycle Mapping Problem
> Plugin execution not covered by lifecycle configuration:
> org.codehaus.mojo:javacc-maven-plugin:2.5:jjtree (execution:
> jjtree-ejbql, phase: generate-sources)    pom.xml
> /cayenne-jdk1.5-unpublished    line 156    Maven Project Build
> Lifecycle Mapping Problem
> Plugin execution not covered by lifecycle configuration:
> org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date
> (execution: date, phase: initialize)    pom.xml
> /cayenne-jdk1.5-unpublished    line 263    Maven Project Build
> Lifecycle Mapping Problem
>
>
>
>
>
> On Sun, Sep 15, 2013 at 3:59 AM, Andrus Adamchik <andrus@objectstyle.org> wrote:
>> Hi Mike,
>>
>> So looks like you are on top of it… Let me know if you need any help.
>>
>> Andrus
>>
>>
>>
>> On Sep 14, 2013, at 8:22 AM, Mike Kienenberger <mkienenb@gmail.com> wrote:
>>> I remembered to update the subject this time.
>>>
>>> So if I replace
>>>
>>>                      arcSnapshot.put(property.getName(), target);
>>>
>>> with
>>>
>>>                      if (property.getRelationship().isUsedForLocking()) {
>>>                            arcSnapshot.put(property.getName(), target);
>>>                      }
>>>
>>> then the primary key qualifier is correct: "WHERE USER_ID = 2" instead
>>> of "WHERE USER_ID is null."
>>>
>>> Unfortunately, this also causes several unit tests to fail.  I haven't
>>> yet investigated why this might be.
>>>
>>> Failed tests:
>>>  testReadToOneRelationship(org.apache.cayenne.access.NestedDataContextReadTest)
>>>  testRemoveToMany(org.apache.cayenne.CDOSetRelationshipTest)
>>>  testRemove(org.apache.cayenne.CDOMany2OneTest)
>>>  testNullifyToOne(org.apache.cayenne.access.NestedDataContextWriteTest)
>>>  testMultipleToOneDeletion(org.apache.cayenne.unit.jira.CAY_901Test)
>>>  testRemoveToMany(org.apache.cayenne.CDOMapRelationshipTest)
>>>  testPhantomRelationshipModificationValidate(org.apache.cayenne.access.DataContextExtrasTest)
>>>  testRemove1(org.apache.cayenne.CDOOne2ManyTest)
>>>  testRemove2(org.apache.cayenne.CDOOne2ManyTest)
>>>  testIsToOneTargetModified(org.apache.cayenne.access.DataRowUtilsTest)
>>>  testRemoveToMany(org.apache.cayenne.CDOCollectionRelationshipTest)
>>>
>>> So far, basic functionality for my app seems working.
>>>
>>> On Fri, Sep 13, 2013 at 4:46 PM, Mike Kienenberger <mkienenb@gmail.com>
wrote:
>>>> As I mentioned earlier, I'm upgrading my ancient Cayenne project from
>>>> 1.1 to 3.x, currently 3.0.2.
>>>>
>>>> I started by upgrading to 1.2 and 2.0, unfortunately hitting the old
>>>> null-relationship-breaks-optimistic-locking error.
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/200803.mbox/%3C8f985b960803271232s5018a5a9hbf0f731f82666e6a@mail.gmail.com%3E
>>>>
>>>> Since most everything else seemed to be working, and the the
>>>> workaround I had for 1.1 wasn't possible in 1.2/2.0, I decided to skip
>>>> ahead to 3.0 and hope it was fixed there, or that it'd be more
>>>> relevant to fix there.
>>>>
>>>> But the same behavior I see in 1.2 and 2.0 still occurs in 3.0.2.  For
>>>> 1.1, the fix was to retain a new snapshot when resolving faults, but
>>>> the problem here seems to be slightly different.
>>>>
>>>> My model has a "User" object and a "PotentialCustomer" object.  The
>>>> PotentialCustomer is an optional one-to-one relationship with the
>>>> User, where they both have the same primary key.  In the past I have
>>>> left the PotentialCustomer relationship as "Used for Locking",
>>>> although I've set it both ways without changing the resulting error.
>>>>
>>>> Committing an unrelated attribute change to the "User" object when it
>>>> has no corresponding "PotentialCustomer" object generates a "where
>>>> USER_ID is null" clause.
>>>>
>>>> Writing a property change eventually generates an  arcSnapshot for all
>>>> to-one relationships, even if they are not marked for locking.
>>>> org.apache.cayenne.access.ObjectDiff.java - line 114:
>>>>
>>>>                public boolean visitToOne(ToOneProperty property) {
>>>>
>>>>                    // eagerly resolve optimistically locked relationships
>>>>                    Object target = lock ?
>>>> property.readProperty(object) : property
>>>>                            .readPropertyDirectly(object);
>>>>
>>>>                    if (target instanceof Persistent) {
>>>>                        target = ((Persistent) target).getObjectId();
>>>>                    }
>>>>                    // else - null || Fault
>>>>
>>>>                    arcSnapshot.put(property.getName(), target);
>>>>                    return true;
>>>>                }
>>>>
>>>> The problem is that with a relationship which is optional, the target
>>>> is going to be null.   And later on, when we generate optimistic
>>>> locking qualifiers in
>>>> org.apache.cayenne.access.DataNodeSyncQualifierDescriptor, we store
>>>> this null value as the matching value for the record's primary key.
>>>>
>>>> To me, part of the fix would seem to be to not do anything if we're
>>>> not locking on this column.   Why do we need to resolve a relationship
>>>> or store a snapshot for a column not involved in optimistic locking?
>>>>
>>>> Second, even if this column is involved with optimistic locking, it
>>>> should not be used as a replacement value for the modified object's
>>>> primary key.  It's probably a model error to specify a relationship
>>>> based on the modified object's primary key as a locking column.
>>>> However, I can correct this by removing the "Used for Locking" value.
>>>>
>>>>
>>>> On Thu, Mar 27, 2008 at 3:32 PM, Mike Kienenberger <mkienenb@gmail.com>
wrote:
>>>>> Here's an interesting situation I'm debugging now for Cayenne 1.1.
>>>>> It seems to be related to CAY-213 "NullPointerException in
>>>>> ContextCommit with locking".  I suspect that it's true of 1.2 and
>>>>> could very well be true for 3.0 as well, although I don't have that
>>>>> handy to test with.
>>>>>
>>>>> http://issues.apache.org/cayenne/browse/CAY-213
>>>>>
>>>>> My testing seems to reveal that the same problem occurs when you set
a
>>>>> to-one relationship to null.  Line 291 in removeToManyTarget() sets
>>>>> the state of the previous to-one relationship object to MODIFIED, but
>>>>> doesn't retain a snapshot for that object.
>>>>>
>>>>> Here's some simple test code that shows the problem.   And switching
>>>>> the scalar setter with the relationship setter works around the
>>>>> problem.
>>>>>
>>>>> It seems to me that the the fix is to add
>>>>>
>>>>>            dataContext.getObjectStore().retainSnapshot(this);
>>>>>
>>>>> as was done for writeProperty().
>>>>>
>>>>>
>>>>>    public void run() throws Exception
>>>>>    {
>>>>>        initCayenne("cayenne.xml");
>>>>>
>>>>>        // Set up database
>>>>>        createSchemaForObjEntityName(Configuration.getSharedConfiguration(),
>>>>> "PotentialCustomer");
>>>>>        DataContext dc = DataContext.createDataContext();
>>>>>
>>>>>        // Set up test data
>>>>>        PotentialCustomer pc =
>>>>> (PotentialCustomer)dc.createAndRegisterNewObject(PotentialCustomer.class);
>>>>>        Premise premise = (Premise)dc.createAndRegisterNewObject(Premise.class);
>>>>>        pc.setToOneTarget("premise", premise, true);
>>>>>        dc.commitChanges();
>>>>>
>>>>>        // Force failure:
>>>>>        pc.setToOneTarget("premise", null, true);
>>>>>        premise.writeProperty("altitude", new Integer(0));
>>>>>
>>>>> // On commitChanges(), no snapshot available for building locking
>>>>> //      java.lang.NullPointerException
>>>>> //          at org.objectstyle.cayenne.access.ContextCommit.appendOptimisticLockingAttributes(ContextCommit.java:564)
>>>>>
>>>>>        dc.commitChanges();
>>>>>    }
>>>>>
>>>>>
>>>>> java.lang.NullPointerException
>>>>>        at org.objectstyle.cayenne.access.ContextCommit.appendOptimisticLockingAttributes(ContextCommit.java:564)
>>>>>        at org.objectstyle.cayenne.access.ContextCommit.prepareUpdateQueries(ContextCommit.java:426)
>>>>>        at org.objectstyle.cayenne.access.ContextCommit.commit(ContextCommit.java:156)
>>>>>        at org.objectstyle.cayenne.access.DataContext.commitChanges(DataContext.java:1266)
>>>>>        at org.objectstyle.cayenne.access.DataContext.commitChanges(DataContext.java:1236)
>>>>>        at com.gvea.cayenne.TestOptimisticLockingFailureOnSingleTargetNull.run(TestOptimisticLockingFailureOnSingleTargetNull.java:110)
>>>>>        at com.gvea.cayenne.TestOptimisticLockingFailureOnSingleTargetNull.main(TestOptimisticLockingFailureOnSingleTargetNull.java:24)
>>>>>
>>>>> Note that some of these line numbers may vary as my version of Cayenne
>>>>> 1.1 has local mods.
>>>
>>

Mime
View raw message