RE: NPE in DataDomainQueryAction.java

From: Kevin Menard (kmenar..ervprise.com)
Date: Thu Aug 02 2007 - 21:02:02 EDT

  • Next message: Tore Halset: "Re: [JIRA] Commented: (CAY-811) Meaningful identity columns: user provided PK values are ignored"

    > -----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 : Thu Aug 02 2007 - 21:02:33 EDT