Many thanks, Andy, for the clarification. I am still not sure which of the following statements describes the best the behaviour I observe: it is (a) the intended behaviour, (b) not intended, just happens to be like this or (c) a bug.
After regarding cache level: reading fleetingly through the JDO specification (3.0), nothing sticks out to indicate that the JDO implementation is supposed to manage any other cache than the second level cache. (void evictAll() itself is listed under the *11.8 Second-level cache management* section.) I am not sure what Level 1 cache may be...is it, perhaps, an artifact of the datanucleus implementation? Thanks Peter On Wed, Jan 4, 2012 at 6:04 AM, datanucleus <[email protected]>wrote: > As for the problem of the original poster, evictAll is for the > *Level1* cache (which will not be of any use since you aren't using > transactions there). Calling addLabels is queued (doesn't go straight > to the DB in the version you use there), and you don't then start a > transaction. Simple thing to do to get around it would be > pm.currentTransaction().begin(); > pm.currentTransaction().commit(); > after the addLabels. > > You can help yourself by looking at the log, since it explains way > more than that (at DEBUG level). > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
