Programmieren mit Harald R. Haberstroh

Da bei normalen "Remote-Objekten" immer ganze Objekte übertragen werden, hat man echtes Call-By-Value. Man arbeitet also mit Kopien von Objekten. Das gilt sowohl für Objekte, die an eine Methode eines Remote-Objekts übergeben werden als auch für Objekte als Returnwerte.
Normalerweise werden innerhalb einer JVM Objekte immer als Referenz übergeben bzw. zurückgegeben. Über RMI werden die Objekte immer serialisiert und komplett übertragen.
Das wirkt sich bei unserem "Data-Beispiel" so aus, dass Updates erst "sichtbar" werden, wenn die Daten auch wieder von der Datei geladen werden. Sollte das Locking direkt in der Record-Implementierung erfolgen, so muss man bedenken, dass auch immer ein Record-Objekt übertragen wird und der Client mit einer Kopie arbeitet. Damit bekommt er immer den Lock!
Abhilfe?
Man darf dem Client nur Referenzen zur Verfügung stellen. Nur der Server arbeitet mit den "echten" Objekten. - Klar, und wie geht das?
Das herauszufinden war nicht einfach, die Java-Dokumentation von Sun (Oracle) schweigt sch diesbezüglich aus, zumindest was direkte Lösungsvorschläge und Beispielcode angeht.

Grundsätzliche Erklärung und Beispiele zur Funktionsweise von RMI hilft etwas: jGuru: Remote Method Invocation (RMI) aber die letzte zündende Idee bekommt man durch How to return object and return object reference in Java RMI

Der Unterschied liegt in der Klassendefinition. Wenn die Klasse eine Unterklasse von UnicastRemoteObject ist, so ist sie damit RMI-fähig (kann RMI-Service anbieten). In diesem Fall wird also eine Referenz zurückgegeben werden. Wenn die Klasse nur Serializable implementiert, so ist die Klasse nicht für RMI-Aufrufe geeignet (kein RMI-Service) und es wird das Objekt zurückgegeben werden.

Ein Beispiel wird in Kürze geliefert.

Labels: Java, PR5