Действительно ли HttpSession ориентирован на многопотоковое исполнение, устанавливаются/получаются Атрибут ориентированные на многопотоковое исполнение операции?
Генератор кода
Мы видели много идей от сериализации по сравнению с ручной реализацией до отражения, и я хочу предложить совершенно другой подход с использованием CGbR Code Generator . Генерирующий клон-метод - это память и центральный процессор, а в 300 раз быстрее, чем стандартный DataContractSerializer.
Все, что вам нужно, это частичное определение класса с ICloneable, а генератор делает остальные:
public partial class Root : ICloneable
{
public Root(int number)
{
_number = number;
}
private int _number;
public Partial[] Partials { get; set; }
public IList Numbers { get; set; }
public object Clone()
{
return Clone(true);
}
private Root()
{
}
}
public partial class Root
{
public Root Clone(bool deep)
{
var copy = new Root();
// All value types can be simply copied
copy._number = _number;
if (deep)
{
// In a deep clone the references are cloned
var tempPartials = new Partial[Partials.Length];
for (var i = 0; i < Partials.Length; i++)
{
var value = Partials[i];
value = value.Clone(true);
tempPartials[i] = value;
}
copy.Partials = tempPartials;
var tempNumbers = new List(Numbers.Count);
for (var i = 0; i < Numbers.Count; i++)
{
var value = Numbers[i];
tempNumbers.Add(value);
}
copy.Numbers = tempNumbers;
}
else
{
// In a shallow clone only references are copied
copy.Partials = Partials;
copy.Numbers = Numbers;
}
return copy;
}
}
Примечание. У последней версии есть более нулевые проверки, но я оставил их для лучшего понимания.
6 ответов
Нет, они не ориентированы на многопотоковое исполнение, по данным IBM - теория Java и практика: все веб-приложения с сохранением информации повреждаются? . Необходимо синхронизироваться.
то, Как HttpSession не ориентирован на многопотоковое исполнение от Ранчо Java, могло бы быть полезным, также.
Сервлет 2,5 спецификации:
Несколько сервлетов, выполняющих потоки запроса, могут иметь активный доступ к тому же объекту сессии одновременно. Контейнер должен гарантировать, что управление внутренними структурами данных, представляющими атрибуты сессии, выполняется ориентированным на многопотоковое исполнение способом. Разработчик несет ответственность за ориентированный на многопотоковое исполнение доступ к самим объектам атрибута. Это защитит набор атрибута в объекте HttpSession от параллельного доступа, устраняя возможность для приложения, чтобы заставить тот набор становиться поврежденным.
Это безопасно:
// guaranteed by the spec to be safe
request.getSession().setAttribute("foo", 1);
Это не безопасно:
HttpSession session = request.getSession();
Integer n = (Integer) session.getAttribute("foo");
// not thread safe
// another thread might be have got stale value between get and set
session.setAttribute("foo", (n == null) ? 1 : n + 1);
Это не , гарантировал, что был безопасен:
// no guarantee that same instance will be returned,
// nor that session will lock on "this"
HttpSession session = request.getSession();
synchronized (session) {
Integer n = (Integer) session.getAttribute("foo");
session.setAttribute("foo", (n == null) ? 1 : n + 1);
}
я видел этот последний защищенный подход (включая в книгах J2EE), но он, как гарантируют, не будет работать спецификацией Сервлета. Вы могли использовать идентификатор сессии для создания взаимного исключения , но должен быть лучший подход.
Нет. И так как Вы не хотите, чтобы тот же клиент (с сессией) сделал параллельные запросы, необходимо сериализировать эти запросы как , AbstractController делает в Spring MVC
До некоторой степени это зависит от Вашего клиентского дизайна.
у Вас есть возможность в Вашем веб-дизайне, чтобы у единственного клиента было несколько выдающихся одновременных запросов с помощью того же Сеанса HTTP? Это кажется трудным сделать, если Вы не связываете единственный Сеанс HTTP с несколькими сокетами. (иначе, Ajax) За исключением выполнения этого, доступ HTTP предоставленного клиента будет однопоточным, что касается сервера, что означает, что единственная сессия эффективно Ориентирована на многопотоковое исполнение.
Синхронизация Ваших объектов сессии подаст заявку, более безопасную против будущих изменений, которые делают Ваше веб-приложение способным к наличию нескольких одновременных запросов, таким образом, это не плохая идея. В современных реализациях Java синхронизация не имеет большой стоимости, которая была ранее связана с нею, особенно когда с синхронизацией обычно не спорят. Если Ваше приложение использует Ajax, который подразумевает, что Вы ожидаете несколько одновременных запросов в полете к своему веб-серверу, то синхронизация - необходимость.
Они не, но большинство времен, Ваши клиенты только получат доступ к ним с единственным потоком.
у Различных клиентов будут различные потоки, и у каждого будет его собственная Сессия.
, Поскольку Eddie указывает, одна ситуация, где можно столкнуться с двумя потоками, получающими доступ к той же сессии, является двумя вызовами ajax, пытаются изменить тот же атрибут сессии. Иначе у Вас не будет проблем.
Сессия не ориентирована на многопотоковое исполнение и ни один получение не, методы установки, как гарантируют, будут ориентированы на многопотоковое исполнение. В целом в контейнере сервлета необходимо принять, чтобы быть в многопоточной среде и не если инструменты безопасны.
Это также идет для объектов, которые Вы храните на сессии. Сама сессия не будет управлять хранившим объектом, но можно получить объект в другом потоке и попытаться управлять им. Вам решать для исследования собственного кода, чтобы видеть, возможны ли условия состязания.
пример кода, который Вы отправили, допустим, но проблема может существовать вне ограниченного объема Вашего примера. Это гарантирует, что нет никаких условий при установке на сессию, но нет ничего предотвращающего другой поток для переопределения набора. Если код в Вашем запросе зависит значения, остающегося неизменным, Вы могли бы все еще быть в беде.