Безопасность потоков Restlet и Google App Engine

Я использую Restlet 2.1.2 в Google App Engine и думаю о его безопасности потоков. <threadsafe> установлено значение true в моей конфигурации GAE.

Как правило, в документации есть примечания о параллелизме для некоторых классов, например. ServerResource является потокобезопасным, и для каждого вызывающего потока создается новый экземпляр. Это означает, что я могу безопасно хранить состояние в переменных-членах (например, параметры из URL-адреса запроса). Кроме того, класс Filter не является потокобезопасным, и один объект этого класса может вызываться несколькими потоками одновременно, поэтому состояние не может быть сохранено в переменных-членах, и что-то вроде ThreadLocal может/должно использоваться.

Кроме того, все подклассы Authenticator небезопасны, потому что они являются подклассами Filter. Authenticators используйте Verifier для проверки учетных данных для входа, и в документации для классов Verifier нет примечания о параллелизме...

Мои вопросы:

1) Могу ли я безопасно хранить некоторое состояние в подклассе Verifier или я должен использовать что-то вроде ThreadLocal? Я думаю, что второй вариант верный. ...Я хочу, чтобы только одно хранилище данных было прочитано, чтобы получить учетную запись пользователя, а затем создать экземпляр User на основе этой информации. Я создаю подкласс SecretVerifier.

2) Есть ли где-нибудь пример/статья с информацией об этих проблемах многопоточности в Restlet в одном месте, а не только в документации? По крайней мере, информация о классах, которые имеют один экземпляр для каждого потока вызывающей стороны и какие экземпляры совместно используются несколькими потоками вызывающей стороны, была бы отличной.


person shelll    schedule 15.05.2013    source источник


Ответы (1)


Во-первых, позвольте мне уточнить, что весь Restlet API был разработан для использования параллельными потоками.

Большинство классов (особенно подклассы org.restlet.Restlet) предназначены для одновременного совместного использования экземпляров несколькими потоками, и поэтому эти классы должны быть потокобезопасными в том смысле, что если они совместно используют переменные между этими потоками, это должно быть через final или volatile поля потокобезопасных классов (классы Concurrent*).

В противном случае всегда можно хранить информацию в самих объектах запроса/ответа, особенно в их свойстве «атрибуты», а не через локальные переменные потока.

Насколько я помню, только подклассы Resource предназначены для одновременного вызова одним потоком, но обратите внимание, что вам все равно придется иметь дело с проблемами видимости потока.

Надеюсь, это прояснит.

person Jerome Louvel    schedule 16.05.2013