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 !!
-~----------~----~----~----~------~----~------~--~---

Reply via email to