Important Notice - Forums is archived
To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
AppEngine servlet doesn't store session after serving resource
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?
thanks
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.
Thanks for the confirmation.
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.