Безопасно ли хранить данные в статическом поле при развертывании в Google App Engine?

Question

Я просматривал код Vosao CMS, открытый исходный код CMS, размещенный на Google App Engine (который я думаю, это огромная идея), и я наткнулся на следующий код внутри CurrentUser класса:

/** 
* 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 «Я никогда не использовал GAE, но это звучит очень странно для меня.

• Является ли GAE действительно «однопоточным»? Безопасно ли хранить данные с областью действия запроса в статическом поле при использовании GAE?

• Означает ли это, что для каждого экземпляра JVM только один HTTP-запрос будет выполнен одновременно, а все остальные запросы ждут?

• Является ли это общей идиомой GAE? Если нет, то какова была бы лучшая идиома GAE для хранения такого UserEntity на время запроса? Разве нельзя использовать ThreadLocal здесь, как в Spring Security? Или какой-то предметный фасоль (управляемый контейнером Injection Dependency)?

Answer 1

Является ли GAE действительно «однопоточным»? Безопасно ли хранить данные с областью действия запроса в статическом поле при использовании GAE?

Это было так (до 1.4.3), и оно по-прежнему по умолчанию.

Теперь, you can specify that your app is threadsafe, а затем вы получите одновременные запросы к тому же JVM/сервлету.

Означает ли это, что для каждого экземпляра JVM будет выполняться только один HTTP-запрос одновременно, а все остальные запросы ждут?

По другому запросу вы, вероятно, получите другую JVM. Но это не под вашим контролем. Они также могут просто ждать.

Answer 2

В настоящее время время автономной работы Java и Python в App Engine одинаково однопоточное; вы правы, что это означает, что на JVM будет выполняться только один HTTP-запрос, но одновременно будут запускаться несколько JVM для обработки нескольких входящих запросов.

Это может измениться в любое время в будущем, однако спецификация Java Servlet допускает многопоточность. В результате вы обязательно должны использовать ThreadLocal.