У меня "в свое время" ни под сферой ни под томкатом таких проблем не было. При том что у нас был параллельный доступ в одному сервлету в одной и той же сессии (несколько одновременный AJAXовских запросов).
Что дальше?

А зачем мне читать у мелкомягких? С каких пор они что-то делают для явы, да еще и не соответсвующее сановской (теперь оракловской) спецификации?
Под вебсферой можно, например, включить сериализацию запросов. По дефолту запросы с доступом к сессии обрабатываются параллельно. Читайте, если можете: www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd....

"Дядя Петя, ты дурак?" (с) Сервлет не хранит референс на сессию (если не полный илиот его писал). Объект класса HttpSession управляется контейнером. Что такое "персистантный сервлет" в вашем воспаленном мозгу я не знаю. Но в жизни все происходит так:
1. Запускается контейнер.
2. Все сервлеты, сконфигурированные как "инициализируйся при запуске" инициализируются, т.е. контейнер создает ОДИН объект и вызывает у него init(...)
3. Если сервлет не инициализирован а к нему приходит запрос, то при первом запросе контейнер создает ОДИН объект и вызывает у него init(...)
4. При каждом запросе, который обрабатывается сервлетом в своем "worker" Thread-е контейнер смотрит сконфигурирован ли у него сервлет для URL запроса. Если да, то контейнер находит наш ЕДИНСТВЕННЫЙ объект для нужного контекста и запускает в этом потоке метод service(...) который определяет что за запрос пришел и запускает подходящий doXXX(...) метод.
Фсё. Одновременно в 100 разных потоках может работать код из метода doGet() одного объекта. В 50 потоках с сессией А а в остальных 50 с сессией Б. В чем проблема-то?
Да, зная вас, оговорюсь - это стандартное поведение. Можно и на томкате и на (насколько я помню) вебсфере заставить для каждого запроса создавать новый объект сервлета и убивать его после обработки запроса. Что неплохо так поднимает нагрузку. Делается в основном только на тестовых серверах, чтобы обеспечить возможность быстро и ненапряжно перегрузить сервлет. Контейнер также может и просто так прибить сервлет (чтобы память освободит, например) вызвав destory() и к этому тоже надо быть готовым (но можно и запретить).
Можно заставить контейнер создавать несколько копий сервлета. Но стандартное поведение - ОДНА копия. Специально для вас - из спецификаций сервлета. Английский вы вроде бы понимаете...


Дядя, я прям вот щас в одном веб-приложении ковыряюсь. Хоть сервлет и не мой. Вы их "когда-то 100500 лет назад вроде бы что-то делал, но забыл", а я последний крупный проект с сервлетами в 2010 делал.
Не врите о том, чего вы не знаете, хорошо?

Уй блин. А если у меня другой класс А хранит в хэшмэпе ссылку на объект класса Б, и доступ к нему только через методы класса А, и он гарантирует что в любой момент у меня только один инстанс класса Б есть, то что, я не могу назвать класс Б (в этом контексте) синглтоном?

Фиговая у вас практика. Ни со спецификацией не соотносится, ни с чужими практиками.

Понял - не слышали. synchronized(...){} никогда не видели?
И код сервера таки зависит от того как его будут запускать. Я могу вам такое написать что при попытке запустить его одновременно без sticky sessions на нескольких хостах за лоадбалансером сервлет будет очень весело работать. Например, можно лезть в контекст. А он, в отличие от сессии между хостами не копируется. Вот же засада, да?

Ога. Потому что веб-разработка это не только странички на cms-ах клепать.

Не профильное это слишком мягко сказано.