С двумя веб-серверами будет ли один одноклассный класс иметь 2 экземпляра?
С 2-мя веб-серверами один класс будет иметь 2 экземпляра?
Ответы
Ответ 1
Оба веб-сервера будут иметь отдельные экземпляры своих прикладных процессов .net или java. Итак, Да, оба сервера будут иметь свои отдельные экземпляры вашего одноэлементного класса.
Независимо от того, что эти два веб-сервера представляют собой две разные физические машины, даже если они находятся на одном сервере, они определенно будут работать полностью на разных процессах. Каждый процесс будет загружать свои объекты в памяти отдельно от любого другого процесса.
specifically in case of asp.net
-
Даже на одном веб-сервере каждый сайт будет вызывать отдельный экземпляр класса Singleton. Поскольку каждый сайт в рабочем процессе asp.net загружается в отдельный домен приложения, ни один из двух доменов не может вмешиваться между объектами друг друга. Таким образом, в случае asp.net даже один веб-сервер, имеющий один рабочий процесс asp.net, может/будет иметь несколько экземпляров одноэлементного класса, каждый отдельно от другого.
Ответ 2
Да, у вас есть Singleton для каждого JVM и даже для загрузчиков классов.
Смотрите Когда используется статья Singleton not a Singleton? (для Java).
Ответ 3
Что вы подразумеваете под "2 веб-серверами"?
Статическое поле (в одиночном режиме) относится к области приложений (в .net).
Итак, если ваши два веб-сервера работают в двух отдельных доменах приложений, тогда да, в противном случае нет.
Ответ 4
На самом деле у вас может быть 2 экземпляра однотонных вызовов на одном веб-сервере, если его часть веб-приложения, развернутого дважды.
В Java загрузчик классов является частью идентификатора класса. Вы можете загрузить один и тот же класс дважды с разными загрузчиками классов, и все статические поля будут существовать дважды. С# имеет аналогичный механизм.
Ответ 5
Можно создать веб-сервер, который будет мультиплексировать через все - соединения, прослушивающие сокеты, даже интерфейсы. Это будет еще один экземпляр класса, только один поток, и, кроме того, довольно небольшой объем памяти. Предостережение заключается в том, что, хотя с самых практических точек зрения это будет выглядеть как два сервера, он все равно будет только одним сервером (и если он сработает, он выйдет из строя целиком...)
Этот подход не так популярен, как многопоточные веб-серверы, хотя, поскольку в то время как он легче на оборудовании, разработчику сложнее справиться - вам нужно явно мультиплексировать между всеми и жонглировать всеми соединениями в неблокирующих вызовах. Если вы создаете дополнительные потоки, ОС отнимает у вас много работы, что позволяет вам писать более многофункциональный сервер.
Конечно, даже в однопоточном сервере нереста второго сервера в отдельной задаче все же возможна, просто пользователем/администратором/тем, кто снова выполняет двоичный код, с другой конфигурацией. Для предотвращения этого требуется довольно симпатичное программирование.
Ответ 6
Вот почему JSP/Servlets обеспечивают идею данных "сеанс" и "приложение". Они должны совместно использоваться серверами в многосерверной среде.
Ответ 7
В качестве расширения этого вопроса, особенно для веб-приложений .NET, вам также необходимо обратить внимание на обработку SessionState. Предполагая, что сеансы не являются "липкими" (пользователь остается на одном веб-сервере после установления сеанса), вам нужно будет сменить SessionState на внепроцессный процесс. Это может быть либо сервер состояния сеанса ASP.NET, либо SQL Server, но ключевым моментом для запоминания является то, что SessionState автоматически не распределяется между серверами, если только вы не разделите его, выйдя из процесса. Кроме того, все, что вы ставите в SessionState, должно быть сериализуемым; добавьте атрибут [Serializable] к любым классам, которые вы используете в SessionState.