Я изучаю книгу "Распределенные системы" (Tanenbaum и Van Steen), и они говорят что-то, что, похоже, противоречит тому, что, по-видимому, многие думают о Java RMI и синхронизированных методах.
Я думал, что использование синхронизированного метода в реализации удаленного объекта (так что реальная реализация, выполняемая на сервере) одновременное выполнение этого метода предотвращается даже тогда, когда вызовы этого метода разные машины клиентов (вызов метода через прокси-сервер... aka the Stub).
Я видел, что у многих людей одинаковое мнение, посмотрите здесь: Вопросы Java RMI и Thread Synchronization
В книге вместо этого сказано, что одновременное выполнение синхронизированных методов не предотвращается при использовании RMI.
Вот соответствующий отрывок из книги (вы можете прочитать только смелое предложение, но вы можете прочитать контекст, если хотите):
Логически, блокирование в удаленном объекте просто. Предположим, что клиент A вызывает синхронизированный метод удаленного объект. Чтобы получить доступ к удаленному объекты всегда выглядят одинаково что касается локальных объектов, то это будет необходимо блокировать А в на стороне клиента, которая реализует объектного интерфейса и к которому A имеет прямой доступ. Аналогично, другой клиент на другой машине необходимо локально блокировать прежде чем его запрос может быть отправлен на сервер. Следствием этого является то, что мы необходимо синхронизировать разные клиенты на разных машинах. Как мы обсуждали в гл. 6, распределенных синхронизация может быть довольно сложной.
Альтернативным подходом было бы разрешить блокировку только на сервере. В принцип, это прекрасно работает, но проблемы возникают при сбое клиента в то время как его обращение обрабатывается сервером. Как мы обсуждали в Глава. 8, мы можем потребовать относительно сложные протоколы для обработки этого ситуации, и которая может существенно влияют на общий производительность удаленного метода вызовы.
Поэтому разработчики Java RMI решили ограничить блокировку удаленные объекты только для прокси (Wollrath et al., 1996). Это означает что потоки в одном и том же процессе будут быть предотвращено одновременно доступа к одному и тому же удаленному объекту, но потоки в разных процессах будут не. Очевидно, что эта синхронизация семантика сложна: при синтаксисе уровень (т.е. при чтении исходного кода) мы можем видеть красивый, чистый дизайн. Только когда распределенное приложение фактически выполненный, непредвиденный может наблюдаться поведение, которое должно были рассмотрены во время разработки. [...]
Я думаю, что статья "Распределенная объектная модель для Java-системы" (доступна здесь) упоминается в тексте примечанием Wollrath et all, 1996 между скобками. Однако единственный соответствующий абзац, который я нашел на этом документе, следующий:
Из-за различных режимов отказа локального и удаленного объекты, распределенное ожидание и уведомление требуют более сложный протокол между участвующими субъектами (так что, например, авария клиента не заставляют удаленный объект блокироваться навсегда), и как такие, не могут быть легко установлены в локальную резьбу модель в Java. Следовательно, клиент может использовать оповещение и ждать методы на удаленной ссылке, но этот клиент должен быть что такие действия не будут связаны с фактическим удаленным объект, только локальный прокси (заглушка) для удаленного объект.
Я интерпретирую текст неправильно или на самом деле заявлено, что синхронизированные методы "не так синхронизированы" при использовании RMI?