Google App Engine : App Caching

• App Server loads an app's code and resource files ---> keeps them in memory to serve multiple requests.
• "app cache" differs slightly between the Python and Java
• the application instance is "running" on the server and responding to requests as events.
• app can store code and data in memory (expects it to be available for subsequent requests handled by the app instance)
• App caching is a mechanisms for speeding up requests    
• NO guarantee that the requests from the same client reach the same server
• NO guarantee that an app instance will stay in memory for any particular amount of time.    
• LAUNCHING NEW INSTANCES: If the app is receiving many requests, App Engine may start new instances on additional servers to spread the load.
• REMOVING APP INSTANCE: If an app instance does not receive a request in a while, the server may purge it from memory to free resources for other apps. Each server frees the least recently used app when it needs more resources.
  

What to store via App Caching

• Cache code (Java classes, Pythong module imports)
• Cache Processed Data NOT SPECIFIC to a given user or request (i.e. configuration, initializaiton info)
  

How to do App Caching

• All of the application's memory is retained in the cache, so using the app cache is a simple matter of storing values in global variables.
• No guarantees for how apps are cached or how requests are distributed, the app cache is not a good choice for persisting data that isn't local to the app instance.
  • alternative 1: use the datastore for permanent reliable storage
  • alternative 2: memcache for app-visible cached data and temporary values.

Java and App Caching on GAE

1. First request GAE gets for Java App -> creates new instance loading code (servlets,etc)
2. 2nd + request -> request is routed to that server are handled by the same JVM instance, with the app's memory preserved between requests, including imported classes and static variables.
   • Reduce the amount of time it takes to handle requests by storing values that apply to all requests in statics, such as data structures parsed from configuration files.
   • When an app accesses data that is global to the JVM, it should do so in a thread-safe manner.
   • App Engine may run multiple request handlers with the same JVM instance simultaneously, each in its own thread. As per the sandbox restriction, request handlers cannot spawn their own threads, but App Engine may use multiple threads to initiate
     request handlers. Using thread safety with global data in a servlet container is a common practice, and this best practice is no different for App Engine.
   • If your servlets must be loaded in a particular order for initialization to succeed, you can control this order using the <load-on-startup> element in the deployment descriptor. This element appears inside the servlet declaration (<servlet>) in web.xml file and contains an
     integer that describes its load order relative to the other servlets (1 for the first, 2 for the second, and so on).

   <servlet> <servlet-name>TestServlet</servlet-name> <servlet-class>TestServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet> <servlet-name>TestServlet2</servlet-name> <servlet-class>TestServlet2</servlet-class> <load-on-startup>2</load-on-startup> this will load 2nd </servlet>