Это безопасно для хранения данных внутри статического поля при развертывании на приложении Google?

Question

Я просматривал код VOSAO CMS., CMS с открытым исходным кодом, принимаемый в Google App Engine (который, я думаю, является потрясающей идеей), и я наткнулся на следующий код внутри Текущий пользователь класс:

/**
 * 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;
        }
}

Я никогда не использовал GAE, но это звучит очень странно для меня.

• Действительно ли «Одиночная резьба»? Безопасно ли сохранить данные охваченных запросов внутри статического поля при использовании GAE?

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

• Это общий Gae Idiom? Если нет, то, что было бы лучшим идиомой Gae для хранения такого пользовательства на протяжении всего запроса? Не следует ли использовать здесь нитоклокаль, например, в весенней безопасности? Или какая-то спешенная фасоль (управляется контейнером впрыска зависимости)?

Answer 1

Действительно ли «Одиночная резьба»? Безопасно ли сохранить данные охваченных запросов внутри статического поля при использовании GAE?

Раньше было таким (до 1,4,3), и он по-прежнему по умолчанию.

Теперь, Вы можете указать, что ваше приложение Threadsafe, а затем вы получите одновременные запросы к тому же JVM / сервлете.

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

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

Answer 2

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

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