Thanks Patrick,
this night I worked around the problem by completely disabling the
data-cache, but it obviously remains a mere workaround.
On Wed, Mar 5, 2008 at 2:31 AM, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I just checked in a change to trunk (r633739) and the 1.0.x branch
> (r633744) that resolves this. The 1.0.3-SNAPSHOT should update with
> the changes in a few hours.
I'll give it a try asap, many thanks.
>
>
> I expect that it's happening because you have some classes that are
> cached with relations to others that are cached, or something like
> that.
Your guess is right ;)!
> You should be able to work around it by making all your classes
> cacheable, and putting the ones that should not be cacheable into a
> cache with size 0.
I'll try this path (which is probably better than completely disabling the
data-cache) should the 1.0.3 snapshot not fix the issue.
Still thanks and best regards,
Francesco
>
>
> -Patrick
>
> On Tue, Mar 4, 2008 at 4:08 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Hi everybody,
> > trying to remove an instance from the datastore by means of the
> > deletion by query I faced an ugly NullPointerException in the
> > mentioned class.
> > Here is the stack-trace:
> >
> > Caused by: java.lang.NullPointerException
> > 00:28:57,406 ERROR [STDERR] at
> > org.apache.openjpa.datacache.QueryCacheStoreQuery
> > $QueryCacheExecutor.clearAccessPath(QueryCacheStoreQuery.java:337)
> > 00:28:57,414 ERROR [STDERR] at
> > org.apache.openjpa.datacache.QueryCacheStoreQuery
> > $QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:345)
> > 00:28:57,420 ERROR [STDERR] at
> > org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1008)
> > 00:28:57,425 ERROR [STDERR] at
> > org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:844)
> > 00:28:57,429 ERROR [STDERR] ... 34 more
> >
> > The affected code, taken from OpenJPA 1.0.2 is the following:
> >
> > /**
> > * Clear the cached queries associated with the access path
> > * classes in the query. This is done when bulk operations
> > * (such as deletes or updates) are performed so that the
> > * cache remains up-to-date.
> > */
> > private void clearAccessPath(StoreQuery q) {
> > if (q == null)
> > return;
> >
> > ClassMetaData[] cmd = getAccessPathMetaDatas(q);
> > if (cmd == null || cmd.length == 0)
> > return;
> >
> > List classes = new ArrayList(cmd.length);
> > for (int i = 0; i < cmd.length; i++)
> > classes.add(cmd[i].getDescribedType());
> >
> > // evict from the query cache
> > QueryCacheStoreQuery cq = (QueryCacheStoreQuery) q;
> > cq.getCache().onTypesChanged(new TypesChangedEvent
> > (q.getContext(), classes));
> >
> > // evict from the data cache
> > for (int i = 0; i < cmd.length; i++)
> > cmd[i].getDataCache().removeAll(
> > cmd[i].getDescribedType(), true);
> > }
> >
> > The failing statement is "cmd[i].getDataCache().removeAll(...)" since
> > "cmd[i].getDataCache()" returns 'null';
> >
> > The point is: given that the "getDataCache()" method is allowed to
> > return 'null', it is not safe (at least) blindly invoking any method
> > without checking the reference returned by the "getDataCache()"
> > method, right?
> > So is this a bug (maybe already known)? How could it be fixed?
> >
> > Please note that this bug (if confirmed) is actually preventing me
> > from using the delete-by-query feature. The only way I can remove an
> > object form the datastore is by loading it into memory for
> > subsequently invoke the its removal. Obviously this is not as
> > efficient as the deletion by query would be.
> >
> > Note: I'm using OpenJPA 1.0.2 along with MySQL 5.0.51a.
> >
> > Thanks in advance,
> > Francesco
> >
> >
>
>
>
> --
> Patrick Linskey
> 202 669 5907
>
