我有一个用于存储一些全局应用程序设置的实体。这些设置可以通过管理 HTML 页面进行编辑，但很少更改。我只有这个实体的一个实例（各种各样的单例），并且当我需要访问设置时总是引用这个实例。
归结为：
class Settings(ndb.Model):
SINGLETON_DATASTORE_KEY = 'SINGLETON'
@classmethod
def singleton(cls):
return cls.get_or_insert(cls.SINGLETON_DATASTORE_KEY)
foo = ndb.IntegerProperty(
default = 100,
verbose_name = "Some setting called 'foo'",
indexed = False)
@ndb.tasklet
def foo():
# Even though settings has already been fetched from memcache and
# should be available in NDB's in-context cache, the following call
# fetches it from memcache anyways. Why?
settings = Settings.singleton()
class SomeHandler(webapp2.RequestHandler):
@ndb.toplevel
def get(self):
settings = Settings.singleton()
# Do some stuff
yield foo()
self.response.write("The 'foo' setting value is %d" % settings.foo)
我假设Settings.singleton()每个请求处理程序调用不止一次会非常快，因为第一次调用很可能会Settings从 memcache 中检索实体（因为实体很少更新），并且同一请求处理程序中的所有后续调用都会检索它来自 NDB 的上下文缓存。从文档中：
上下文缓存仅在单个传入 HTTP 请求期间持续存在，并且仅对处理该请求的代码“可见”。它很快; 这个缓存存在于内存中。
但是，AppStat 显示我的Settings实体在同一个请求处理程序中多次从内存缓存中检索。我通过查看 AppStat 中请求处理程序的详细页面、扩展每个调用的调用跟踪memcache.Get并查看正在接收的 memcahe 密钥来了解这一点。
我在我的请求处理程序中使用了很多小任务，并且我Settings.singleton()从需要访问设置的小任务中调用。这可能是再次从内存缓存而不是从上下文缓存中获取设置实体的原因吗？如果是这样，控制是否/何时可以从上下文缓存中获取实体的确切规则是什么？我无法在 NDB 文档中找到此信息。
2013/02/15 更新：我无法在虚拟测试应用程序中重现这一点。测试代码为：
class Foo(ndb.Model):
prop_a = ndb.DateTimeProperty(auto_now_add = True)
def use_foo():
foo = Foo.get_or_insert('singleton')
logging.info("Function using foo: %r", foo.prop_a)
@ndb.tasklet
def use_foo_tasklet():
foo = Foo.get_or_insert('singleton')
logging.info("Function using foo: %r", foo.prop_a)
@ndb.tasklet
def use_foo_async_tasklet():
foo = yield Foo.get_or_insert_async('singleton')
logging.info("Function using foo: %r", foo.prop_a)
class FuncGetOrInsertHandler(webapp2.RequestHandler):
def get(self):
for i in xrange(10):
logging.info("Iteration %d", i)
use_foo()
class TaskletGetOrInsertHandler(webapp2.RequestHandler):
@ndb.toplevel
def get(self):
logging.info("Toplevel")
use_foo()
for i in xrange(10):
logging.info("Iteration %d", i)
use_foo_tasklet()
class AsyncTaskletGetOrInsertHandler(webapp2.RequestHandler):
@ndb.toplevel
def get(self):
logging.info("Toplevel")
use_foo()
for i in xrange(10):
logging.info("Iteration %d", i)
use_foo_async_tasklet()
在运行任何测试处理程序之前，我确保存在具有键名单例Foo的实体。
与我在生产应用程序中看到的相反，所有这些请求处理程序都memcache.Get在 Appstats 中显示了一次调用。
2013 年 2 月21 日更新：我终于能够在虚拟测试应用程序中重现这一点。测试代码为：
class ToplevelAsyncTaskletGetOrInsertHandler(webapp2.RequestHandler):
@ndb.toplevel
def get(self):
logging.info("Toplevel 1")
use_foo()
self._toplevel2()
@ndb.toplevel
def _toplevel2(self):
logging.info("Toplevel 2")
use_foo()
for i in xrange(10):
logging.info("Iteration %d", i)
use_foo_async_tasklet()
这个处理程序确实在 Appstats 中显示了 2 次调用memcache.Get，就像我的生产代码一样。
实际上，在我的生产请求处理程序代码路径中，我有一个toplevel被另一个调用的toplevel. 似乎 atoplevel创建了一个新的 ndb 上下文。
将嵌套更改toplevel为 a 可以synctasklet解决问题。