Can I build CachingDatastoreService.java right from my GAE project? How? Once built, where would I put it, somewhere in the WAR folder?
Excuse my ignorance.... Baz On Mon, Nov 2, 2009 at 11:31 AM, Vince Bonfanti <[email protected]> wrote: > > 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 !! -~----------~----~----~----~------~----~------~--~---
