cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Zeigler <robe...@puregumption.com>
Subject Re: more fault resolving oddness
Date Sat, 08 Jul 2006 17:52:46 GMT
Sweet! Many thanks!

Robert

Andrus Adamchik wrote:
> Ok, this is fixed. Actually looks like the fix may even have some
> small positive impact on performance, as now less work is being done
> when the object snapshot is taken.
>
> Andrus
>
>
> On Jul 8, 2006, at 12:55 PM, Andrus Adamchik wrote:
>
>> I can confirm this bug. I am working on it now:
>>
>> http://issues.apache.org/cayenne/browse/CAY-592
>>
>> Thanks for doing all this testing!!
>>
>> Andrus
>>
>> On Jul 8, 2006, at 12:52 AM, Robert Zeigler wrote:
>>
>>> I did a bit more research... as of 1.2M11, everything seems cheery. As
>>> of 1.2M12, I get the exceptions. HTH.
>>>
>>> Robert
>>>
>>> Robert Zeigler wrote:
>>>> So, I was testing the 7/7 nightly build to see how the fix for CAY-585
>>>> worked, and I've come across a new issue. I wondered if it was due to
>>>> the fix, :), so I've gone back and tested against nightly build 7/5
>>>> and
>>>> also 1.2RC2, and the problem still exists (so, not from the CAY-585
>>>> fix,
>>>> apparently).  I wasn't sure whether to tag it onto the end of
>>>> CAY-585 or
>>>> not. In any event, you can use the exact same mapping as in CAY-585 to
>>>> reproduce the error. Add the following line to the setUp method:
>>>>
>>>> dc.performGenericQuery(new SQLTemplate(Assignment.class, "delete from
>>>> AssignmentTransaction"));
>>>>
>>>> And then add the following test case:
>>>>
>>>>     public void testCayenneFaultCaseBaseObjectNewContext() {
>>>>         DataContext dc = DataContext.createDataContext();
>>>>         Assignment a = (Assignment)
>>>> DataObjectUtils.objectForPK(dc,Assignment.class,1);
>>>>         AssignmentTransaction at = (AssignmentTransaction)
>>>> dc.createAndRegisterNewObject(AssignmentTransaction.class);
>>>>         at.setAssignment(a);
>>>>         dc.commitChanges();
>>>>
>>>>         dc = DataContext.createDataContext();
>>>>         a = (Assignment)
>>>> DataObjectUtils.objectForPK(dc,Assignment.class,1);
>>>>         at = (AssignmentTransaction) a.getTransactions().get(0);
>>>>         at.setStartTime(new Date());
>>>>         at.getAssignment().getTitle();
>>>>     }
>>>>
>>>>
>>>> This will produce a fault failure exception attempting to resolve the
>>>> object for: <Objectid:Assignmentid:1>.
>>>>
>>>> I also played with the following test case, which produces no
>>>> exception.
>>>>
>>>>     public void
>>>> testCayenneFaultCaseBaseObjectNewContextCleanTransactionFetch() {
>>>>         DataContext dc = DataContext.createDataContext();
>>>>         Assignment a = (Assignment)
>>>> DataObjectUtils.objectForPK(dc,Assignment.class,1);
>>>>         AssignmentTransaction at = (AssignmentTransaction)
>>>> dc.createAndRegisterNewObject(AssignmentTransaction.class);
>>>>         at.setAssignment(a);
>>>>         dc.commitChanges();
>>>>
>>>>         int atpk = DataObjectUtils.intPKForObject(at);
>>>>         dc = DataContext.createDataContext();
>>>>         a = (Assignment)
>>>> DataObjectUtils.objectForPK(dc,Assignment.class,1);
>>>>         at = (AssignmentTransaction)
>>>> DataObjectUtils.objectForPK(dc,AssignmentTransaction.class,atpk);
>>>>         at.setStartTime(new Date());
>>>>         at.getAssignment().getTitle();
>>>>     }
>>>>
>>>>
>>>> A few notes: The exception only occurs if you snag the transaction
>>>> from
>>>> the re-fetched assignment (a.getTransactions()), and it only occurs if
>>>> you modify the transaction so fetched (at.setStartTime). 
>>>> Interestingly,
>>>> before the call to at.setStartTime(new Date()), at.getAssignment()
>>>> works
>>>> fine, and a printout of the persistence state showed it as committed;
>>>> after the call to setStartTime, at.getAssignment().getPersistentState
>>>> shows it in state committed.  This is not the case for the
>>>> non-exception
>>>> producing test case.
>>>> Also, turning off the shared cache gets rid of the error.  Also, it
>>>> does, in fact, matter that the AssignmentTransaction was already
>>>> loaded,
>>>> but doesn't seem to matter exactly how it got loaded. For instance,
>>>> the
>>>> following test case also produces an exception:
>>>>
>>>>     public void
>>>> testCayenneFaultCaseBaseObjectNewContextPriorTransaction() {
>>>>         DataContext dc = DataContext.createDataContext();
>>>>         dc.performGenericQuery(new SQLTemplate(Assignment.class,
>>>> "INSERT
>>>> into AssignmentTransaction (assignmentid,id) VALUES (1,1)"));
>>>>         Assignment a = (Assignment)
>>>> DataObjectUtils.objectForPK(dc,Assignment.class,1);
>>>>         AssignmentTransaction at;
>>>>         a.getTransactions().size();//.size forces the assignment
>>>> transaction above to be faulted...
>>>>         dc = DataContext.createDataContext();
>>>>         a = (Assignment)
>>>> DataObjectUtils.objectForPK(dc,Assignment.class,1);
>>>>         at = (AssignmentTransaction) a.getTransactions().get(0);
>>>>         at.setStartTime(new Date());
>>>>         at.getAssignment().getTitle();
>>>>     }
>>>>
>>>> If you comment out the a.getTransactions().size() line, no exception
>>>> will be produced (and the at.setStartTime does /not/ cause the
>>>> assignment associated with at.getAssignment to wind up HOLLOW).
>>>>
>>>> Robert
>>>>
>>>
>>>
>>
>>
>


Mime
View raw message