Ok, I got the class to compile into the classes folder under: /home/baz/Source/ThinkLOOP-GAE/war/WEB-INF/classes/com/newatlanta/appengine/datastore/CachingDatastoreService.class
How do I call it now, variations of this don't seem to work: <cfobject name="CDS" component="com.newatlanta.appengine.datastore.CachingDatastoreService" type="java" /> Thanks, Baz On Thu, Nov 5, 2009 at 3:05 PM, Vince Bonfanti <[email protected]> wrote: > > You can add it directly to your project just as you would any other > Java class (within your projects's "src" directory, within an > appropriate directory structure to match the package). The class file > will be automatically build into your "war/WEB-INF/classes" directory. > > Vince > > On Thu, Nov 5, 2009 at 3:28 PM, Bassil Karam <[email protected]> wrote: > > 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 !! -~----------~----~----~----~------~----~------~--~---
