google app engine - Objectify inconsistency when getting all entities of a given kind (local Cloud Endpoints) -

i experiencing inconsistencies when trying load entities of given kind, using objectify.

the setup

i running cloud endpoints backend locally, , using following method populate datastore:

  public static void dsup() {     store store1 = new store("h&m", new geopt(new float(56.157702), new float(10.206938)));     store store2 = new store("marc jacobs", new geopt(new float(56.158284), new float(10.208618)));     store store3 = new store("weekday", new geopt(new float(56.158522), new float(10.207547)));      ofy().save().entities(store1, store2, store3).now(); // synchronous save auto generate id } 

after setting database, datastore viewer shows 3 objects created:

the problem

i started noticing client app (ios) received 2 stores:

i revisited getstores() method on backend, , changed loads stores 4 times, logging each try, , returning results first try.

the method (after changing multiple load tries), looks this:

 public static list<store> getstores() {      list<store> result = ofy().load().type(store.class).list();     logger.warning("getting stores, try 1: " + result.tostring());     logger.warning("getting stores, try 2: " + ofy().load().type(store.class).list());     logger.warning("getting stores, try 3: " + ofy().load().type(store.class).list());     logger.warning("getting stores, try 4: " + ofy().load().type(store.class).list());      return result; // returning results try 1 } 

usually, every try returns 3 stores. however, first try, , second try return 2 stores. third , fourth try, stores returned.

the logged output 1 of method calls looks this. notice time both try 1 , 2 returned 2 stores.

i can not see pattern store left out between database resets. one, another. however, seems within same call getstores(), if try 1 , 2 both fails, seems missing same store (like in picture above).

what have tried?

my initial thought must have set objectify filter wrong. however, seems in order far can tell. in webapp/web-inf/web.xml file, have following filter , filter-mapping:

<filter>     <filter-name>objectifyfilter</filter-name>     <filter-class>com.googlecode.objectify.objectifyfilter</filter-class> </filter> <filter-mapping>     <filter-name>objectifyfilter</filter-name>     <url-pattern>/*</url-pattern> </filter-mapping> 

i not familiar objectify's caching yet, tried following:

adding following line first thing in getstores() method on backend, before loading entities:

  ofy().clear(); // clear cache 

i have tried using strong consistency when loading entities, follows:

    list<store> result = ofy().consistency(readpolicy.consistency.strong).load().type(store.class).list(); 

other info might relevant

i can recreate inconsistency , happens 1/5 times. however, far can tell, happens after setting database scratch, using dsup() method mentioned earlier.

between tries use following method clear database:

public static void dsdown() {     list<key<store>> allstorekeys = ofy().load().type(store.class).keys().list();     ofy().delete().keys(allstorekeys).now(); } 

as far datastore viewer concerned, dsdown() method works intended , leaves database empty. far understand, deleting entities directly in database viewer cause problem cache isn't deleted. have read deleting entities using objectify in dsdown() method circumvents problem.

if there additional info should provide, please let me know.

thanks!

edit (with implementation of solution @saiyr):

as @saiyr notes, datastore simulates eventual consistency when running locally, caused inconsistency. following screenshots show how added flag backend module's build.gradle file.

nb: note if turn simulated eventual consistency off (setting flag 0) can cause error objectify transactions. why set flag 1 instead. see this stack overflow post more information on this.

you want add flag backend project's build.gradle file:

the dev server datastore emulates eventual consistency. setting consistency strong in objectify no-op, because can't enforce strong consistency on non-ancestor queries. dev server, can try setting datastore.default_high_rep_job_policy_unapplied_job_pct value 0 around behavior, note affects local development.