Would someone more familiar with the caching stuff be willing to take
a look at my synopsis? I can generate a test case if that'd help,
but if the proposed fix does the trick, we can go ahead and commit
it. I just don't want to be negatively impacting performance based
on misunderstanding of what may be going on.
Thanks,
Kevin
On Aug 2, 2007, at 9:02 PM, Kevin Menard wrote:
> > -----Original Message-----
> > From: Andrus Adamchik [mailto:andru..bjectstyle.org]
> > Sent: Thursday, August 02, 2007 6:21 PM
> > To: de..ayenne.apache.org
> > Subject: Re: NPE in DataDomainQueryAction.java
> >
> > > Anyway, if you have any idea what's going on, great. If not, I'll
> > dig
> > > in more. I just wanted to check before wasting effort.
> >
> > Nothing immediately obvious, but then it is past 1 am in my timezone
> :-
> > )
>
> So, I looked into it some more and unfortunately I have some
> confounding
> variables. Someone here changed the model on me to make one of the
> entities reflexive. The problem ends up being in
> AshwoodEntitySorter#findReflexiveMaster. It has the following:
>
> // find committed snapshot - so we can't fetch from the
> context
> as it will return
> // dirty snapshot; must go down the stack instead
> ObjectIdQuery query = new ObjectIdQuery(
> object.getObjectId(),
> true,
> ObjectIdQuery.CACHE);
>
> This creates an ObjectIdQuery that should pull its value from cache.
> Since this is an INSERT, there's no way for the ID to be cached.
> That,
> or because I've disabled caching. I can't really tell which. Either
> way, there's no cache. So, when this finally gets down into
> DataDomainQueryAction, it checks if a cache refresh should be
> performed,
> comes back false, and tries to pull the value of a cache that doesn't
> exist, resulting in an NPE. (Side note, maybe using the NullObject
> pattern here wouldn't be so bad).
>
> Anyway, changing the code to the following worked for me:
>
> // find committed snapshot - so we can't fetch from the
> context
> as it will return
> // dirty snapshot; must go down the stack instead
> ObjectIdQuery query = new ObjectIdQuery(
> object.getObjectId(),
> true,
> ObjectIdQuery.CACHE_REFRESH);
>
> Note in this case, we're saying to ignore the cache.
>
> I don't have a firm enough understanding of the rest of the code to
> tell
> whether or not this is problematic. At worst, I'd guess it may be a
> performance issue for some. But forcing a cache refresh shouldn't
> cause
> any data invalidation.
>
> This may have been around since 2.0.x. Like I said, with the two
> changes at once, I haven't deduced that yet. I'll have to try
> firing up
> with 2.0.3 tomorrow to see.
>
> --
> Kevin
>
>
>
This archive was generated by hypermail 2.0.0 : Wed Aug 08 2007 - 18:03:33 EDT