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:[EMAIL PROTECTED]
> Sent: Thursday, August 02, 2007 6:21 PM
> To: [email protected]
> 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
