I was browsing through the code of Vosao CMS, an open source CMS hosted on Google App Engine (which I think is an awesome idea), and I stumbled upon the following code inside the CurrentUser class:
/**
* Current user session value cache class. Due to GAE single-threaded nature
* we can cache currently logged in user in static property. Which we set in
* authentication filter.
*/
public class CurrentUser {
private static UserEntity user;
public static UserEntity getInstance2() {
return user;
}
public static void setInstance2(UserEntity aUser) {
user = aUser;
}
}
I've never used GAE, but this sounds really weird to me.
Is GAE really "single threaded"? Is it safe to store request-scoped data inside a static field when using GAE?
Does this mean that, for each JVM instance, only one HTTP request will be executed at a time, while all the other requests are waiting?
Is this a common GAE idiom? If not, what would be the best GAE idiom to store such an UserEntity for the duration of a request? Shouldn't one use a ThreadLocal here, like they do in Spring Security? Or some kind of scoped bean (managed by the Dependency Injection container)?
Is GAE really "single threaded"? Is it safe to store request-scoped data inside a static field when using GAE?
It used to be that way (until 1.4.3) and it still is by default.
Now, you can specify that your app is threadsafe, and then you will receive concurrent requests to the same JVM/servlet.
Does this mean that, for each JVM instance, only one HTTP request will be executed at a time, while all the other requests are waiting?
For other request, you would probably get another JVM. But that is outside of your control. They can also just wait.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With