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