In my application, I have a stream resource. Internally, in the getStream method of the StreamSource, I change some of the fields to do a little caching so that a second request for that resource can be served more quickly.
However, it appears that the AppEngine servlet is not storing the session data after serving the request. So when a second request is received, the program uses the old state, without any of the cached data.
I’ve also tried to remove and re-add the resource to the application, but that does not seem to help in any way.
I’ve tried to analyze the GAEApplicationServlet and it appears that requests for ApplicationResource do follow a different path then other requests.
Is my suspicion correct? Is there another better way of doing this?
This is by design as the distributed nature of Google App Engine requires quite expensive locking to avoid corrupting the session data if there are multiple simultaneous requests for the same session going to different server instances. To reduce the amount of locking required, resource requests are handled without locking and are thus not allowed to update the session. This is documented in the Notes and Limitations for Google App Engine section of the release notes.
I guess you could circumvent this by using a custom version of GAEApplicationServlet where the if (requestType == RequestType.APPLICATION_RESOURCE) block is removed from the beginning of the service method. Please note that I haven’t tested this out in practice.
If you have some reliable way of knowing which resource requests will update the session, you could also try changing the if clause to only ignore those requests but still handle other application resource requests without locking.
I can understand the reasons behind the decision and I don’t want to mess with this. I’m going to figure out another way around this. Probably by doing the caching operations at the time the resource is created and not when it is requested.