No, that's not possible. Vince
On Mon, Nov 9, 2009 at 4:07 PM, Bassil Karam <[email protected]> wrote: > Any word on whether I can manually drop-in the CachingDatastoreService to > replace the DatastoreService transparently? > > Baz > > > On Fri, Nov 6, 2009 at 6:20 AM, Paul Bonfanti <[email protected]> wrote: > >> Change your cfobject tag from this: >> >> >> >> <cfobject name="CDS" >> component="com.newatlanta.appengine.datastore.CachingDatastoreService" >> type="java" /> >> >> >> >> To this: >> >> >> >> <cfobject name="CDS" >> class="com.newatlanta.appengine.datastore.CachingDatastoreService" >> type="java" action=”create” /> >> >> >> >> Then it should work. >> >> >> >> Paul >> >> >> >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *Bassil Karam >> *Sent:* Thursday, November 05, 2009 7:27 PM >> *To:* [email protected] >> *Subject:* [OpenBD] Re: GAE - Application Scope, Session Scope and >> Memcached >> >> >> >> The error is: >> >> >> >> >> >> Type >> >> Internal >> >> Tag Context >> >> CFOBJECT (/home/baz/Source/ThinkLOOP-GAE/war/index.cfm, Line=1, Column=1) >> >> Source >> >> 1: <cfobject name="CDS" >> component="com.newatlanta.appengine.datastore.CachingDatastoreService" >> type="java" /> >> >> 2: <cfdump var="#CDS#"> >> >> 3: <cfabort> >> >> 4: <cfsilent> >> >> 5: <cfif not StructKeyExists(url, 'think')> >> >> ^ Snippet from underlying CFML source >> >> Stack Trace >> >> java.lang.NullPointerException >> >> at com.naryx.tagfusion.cfm.tag.cfOBJECT.render(Unknown Source) >> >> at com.naryx.tagfusion.cfm.tag.cfTag.coreRender(Unknown Source) >> >> at com.naryx.tagfusion.cfm.tag.cfTag.render(Unknown Source) >> >> at com.naryx.tagfusion.cfm.file.cfFile.render(Unknown Source) >> >> at com.naryx.tagfusion.cfm.engine.cfSession.onRequest(Unknown Source) >> >> at com.naryx.tagfusion.cfm.engine.cfEngine.service(Unknown Source) >> >> at com.naryx.tagfusion.cfm.cfServlet.service(Unknown Source) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) >> >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) >> >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) >> >> at >> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> >> at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) >> >> at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) >> >> at >> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) >> >> at >> com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54) >> >> at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:268) >> >> at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) >> >> at >> com.google.appengine.tools.development.StaticFileUtils.serveWelcomeFileAsForward(StaticFileUtils.java:80) >> >> at >> com.google.appengine.tools.development.LocalResourceFileServlet.maybeServeWelcomeFile(LocalResourceFileServlet.java:247) >> >> at >> com.google.appengine.tools.development.LocalResourceFileServlet.doGet(LocalResourceFileServlet.java:120) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) >> >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) >> >> at >> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) >> >> at >> com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43) >> >> at >> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) >> >> at >> com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121) >> >> at >> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) >> >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) >> >> at >> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> >> at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) >> >> at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) >> >> at >> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) >> >> at >> com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54) >> >> at >> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) >> >> at >> com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:342) >> >> at >> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) >> >> at org.mortbay.jetty.Server.handle(Server.java:313) >> >> at >> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) >> >> at >> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) >> >> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) >> >> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) >> >> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) >> >> at >> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) >> >> at >> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) >> >> >> >> On Thu, Nov 5, 2009 at 4:12 PM, Bassil Karam <[email protected]> wrote: >> >> 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 !! -~----------~----~----~----~------~----~------~--~---
