Query caching and page caching in BD are currently implemented via memory-based caches. So, yes, they would exist on a per-application-instance basis in GAE. We plan to modify these in OpenBD-GAE to use memcache.
I'd recommend just building the CachingDatastoreServvice class--it doesn't have any dependencies on the rest of GaeVFS. Vince On Mon, Nov 2, 2009 at 2:08 PM, Bassil Karam <[email protected]> wrote: > > Very interesting Vince. So far from my informal tests, I can tell you > that my app scope resets several times a day at least. So I see what > you mean when you say it wouldn't be best for framework > initialization. Also inappropriate would be object pools, or temporary > cache's that get flushed to the db as a batch. I take it query caching > and page caching also rely on the same mechanisms and have the same > gotchas? Come to think of it, are those even wired up? > > Next I will play around with memcached and your > CachingDatastoreService if I can figure out how to build it and > replace the current GAE-VFS. > > Cheers, > Baz > > > > > On Mon, Nov 2, 2009 at 9:00 AM, Vince Bonfanti <[email protected]> wrote: >> >> RE: "could application.myvariable return different values depending on >> which machine it pulls it from? What about session scope?" >> >> I asked this question on the GAE forum--more than once--back in June, >> and never received a direct answer. However, the Servlet spec (version >> 2.4) has this to say (Section SRV.3.4.1): >> >> "Context attributes are local to the JVM in which they were >> created. This prevents ServletContext attributes from being a shared >> memory store in a distributed container. When information needs to be >> shared between servlets running in a distributed environment, the >> information should be placed into a session (See Chapter SRV.7, >> “Sessions”), stored in a database, or set in an Enterprise JavaBeansTM >> component." >> >> Therefore, my assumption is that there will be a separate >> ServletContext for each JVM instance--and possibly each application >> instance, if within the same JVM--that is created by GAE. (I posted >> this assumption on the GAE forum and was not contradicted--though also >> not confirmed either). >> >> Because the CFML Application scope in BD is implemented on top of the >> ServletContext, you will therefore get a different Application scope >> for each instance of your application created by GAE. So yes, >> "application.myvariable" might return different values for different >> instances of your application, just as it would if your application >> was deployed on several different servers within a cluster. >> >> According the GAE documentation: "App Engine includes an >> implementation of sessions, using the servlet session interface. The >> implementation uses the App Engine datastore and memcache to store >> session data." While I haven't tested this (yet), the implication is >> pretty clear than sessions are shared across instances of your >> application. Therefore "session.myvariable" should always return the >> same value across multiple instances of your application. Note that >> sessions are disabled by default and must be explicitly enabled; see >> the heading Enabling Sessions on the following page: >> >> http://code.google.com/appengine/docs/java/config/appconfig.html >> >> RE: "Will the app scope be reset quite often as machines spin up and down?" >> >> Possibly, yes. Google has not been very forthcoming regarding what to >> expect regarding how often and under what circumstances new instances >> of your application will be created or destroyed. >> >> RE: "Will it be the recommendation of openbd to favor memcached >> instead of those scopes?" >> >> Using the Session scope for per-user data is probably best. Doing >> "heavy" initialization of the Application scope is probably not a good >> idea; many applications and frameworks do this under the assumption >> that application initialization happens only once, but GAE turns this >> assumption on its head. It might be best to look to memcache to store >> data that might otherwise be stored in the Application scope, >> especially if you need to share this data across multiple instances of >> your application. >> >> RE: "what's the status and plans for memcached integration? Will it be >> transparently linked to the app scope, or will there be a specific set >> of functions to interact with it?" >> >> It's not likely that we'll transparently link the Application scope to >> memcache (though this is an interesting idea). One thought is to >> emulate the "Cluster" scope introduced by Railo and implement that >> scope on memcache (possibly backed by the datastore). Otherwise, we'll >> provide a specific set of functions to interact with memcache. >> >> RE: "For now, should I just use the datastore as my cache instead of >> app scope, session scope or memcached?" >> >> I would use the Session scope just as you normally would. For the >> Application scope, it depends what you're doing. If you're doing >> fairly lightweight initialization of values that don't change during >> the application lifetime, then I'd continue using the Application >> scope. If you're doing "heavy" initialization, or storing variables >> whose values change during the application lifetime, then I'd consider >> use CFOBJECT to interact with memcache directly (it would be pretty >> easy to write a set of CFML UDFs--or a CFC--to do this). I'd recommend >> using the low-level API rather than JCache: >> >> http://code.google.com/appengine/docs/java/memcache/ >> >> If you're feeling really adventurous, you might want to take a look at >> using the CachingDatastoreService (again, via CFOBJECT) that I've >> implemented for GaeVFS. This allows you to store values in the >> datastore with automatic caching in memcache: >> >> >> http://code.google.com/p/gaevfs/source/browse/trunk/src/com/newatlanta/appengine/datastore/CachingDatastoreService.java >> >> Note that the CachingDatastoreService is *not* included in the latest >> GaeVFS download, so you'll have to download the source and build it >> yourself. >> >> RE: "Additionally, does onApplicationStart() get invoked every time a >> new server spins up?" >> >> Yes. >> >> On Sun, Nov 1, 2009 at 4:24 PM, Bassil Karam <[email protected]> wrote: >>> >>> The way I understand it, GAE spins up and spins down servers to meet >>> the needs of an app - or even just because it feels like it. What >>> effects does this have on the *persistent* scopes (sorry Sean I know >>> you hate them being called that :) like application and session? More >>> specifically: >>> >>> - Are those scopes synchronized between machines? That is, could >>> application.myvariable return different values depending on which >>> machine it pulls it from? What about session scope? >>> - Will the app scope be reset quite often as machines spin up and down? >>> - Will it be the recommendation of openbd to favor memcached instead >>> of those scopes? >>> >>> Which leads me to my next question: what's the status and plans for >>> memcached integration? Will it be transparently linked to the app >>> scope, or will there be a specific set of functions to interact with >>> it? For now, should I just use the datastore as my cache instead of >>> app scope, session scope or memcached? >>> >>> Thanks, >>> Baz >>> >>> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
