Используя Java RMI, когда именно сериализованный объект передается по сети? - PullRequest
1 голос
/ 10 августа 2009

Я использую RMI для реализации некоторого распределенного алгоритма, и, поскольку мы передаем довольно большие объекты, я хотел бы получить некоторую точность относительно того, когда RMI передает сериализованные объекты по сети.

Предположим, у меня удаленный класс с использованием следующего метода.

class MyServer extends Remote {
    public synchronized void foo (Bar bar) {
        ...
        Thread.wait();
        ...
    }
}

Теперь у меня есть два (или более) клиента RMI, вызывающих метод MyServer.foo. Когда Клиент 1 вызывает его, он блокируется в Thread.wait () . Затем Клиент 2 вызывает foo , и он блокируется, потому что Клиент 1 все еще использует метод foo , который синхронизирован.

Теперь возникает вопрос: когда по сети передается bar параметр Client 2 call? Только один раз Клиент 2 может реально ввести метод foo или раньше, когда он заблокирован?

Дополнительный вопрос: является ли это (время, в которое объекты передаются) поведением, которое обеспечивается спецификациями RMI, или это зависит от реализации?

Ответы [ 2 ]

1 голос
/ 10 августа 2009

Параметр bar передается в том же запросе, что и запрос для вызова метода foo, который является частью протокола RMI .

1 голос
/ 10 августа 2009

В вашем примере, похоже, есть пара проблем.

Я предполагаю, что Thread.wait () - это на самом деле this.wait (), поскольку в Thread такого метода нет. И ожидание должно быть вызвано для того же объекта, который используется для выполнения синхронизации.

Предполагая, что, когда Клиент 1 вызывает lock.wait (), монитор в блоке синхронизации освобождается. Это означает, что Клиент 2 может получить доступ к методу и в конечном итоге заблокируется при том же методе ожидания. Функция wait () будет освобождена, когда другой поток вызовет notify () для того же экземпляра MyServer.

Что касается сериализации, которая происходит до вызова этого метода. Это произошло бы в коде RMI, который вызывает этот метод.

...