# Hibernate über RMI



## Ice-Tea (23. Jan 2009)

Hallo,
Ich habe einen RMI Client sowie einen Server. Der Server startet eine DerbyDB und verbindet sich damit.

Der Client verbindet sich über RMi mit dem Server und bekommt so zugriff auf die JPAController.

Mein vorhaben ist es, die Hibernate-Bibliotheken nur dem Server mitzugeben.
Der Client soll möglichst klein bleiben.

Das klappt auch alles ganz gut, nur bekommt der Client beim Aufruf der Remote-Methode eine reference auf die JPAController Klasse. (Der Client läd die Klasse nach und braucht entsprechent ein paar Hibernate Klassen. Außerdem versuct der Client bei LAzY-abfragen sich direkt mit dem DerbyServer zu verbinden, was nicht sein soll)
Jetzt ist die Frage ob ich das durch ein ArrayCopy in der RemoteFacade lösen kann , oder ob ich einen ganz anderen weg einschlagen muss.

Hier ist eine meiner RemoteFacaden

```
public class ZutatJpaFacade extends UnicastRemoteObject implements ZutatJpaFacadeRemote {

    private volatile ZutatJpaController zutatJpaController;

    public ZutatJpaFacade(
final ZutatJpaController zutatJpaController,
 final int port, final RMIClientSocketFactory csf,
 final RMIServerSocketFactory ssf) throws RemoteException {
        super(port, csf, ssf);
        this.zutatJpaController = zutatJpaController;
    }

    public ZutatJpaFacade(
final ZutatJpaController zutatJpaController,
 final int port) throws RemoteException {
        super(port);
        this.zutatJpaController = zutatJpaController;
    }

    public void create(kochstudio.entity.Zutat zutat) {
        try {
            zutatJpaController.create(zutat);
        } catch (PreexistingEntityException ex) {
            Logger.getLogger(ZutatJpaFacade.class.getName()).log(Level.SEVERE, null, ex);
        } catch (Exception ex) {
            Logger.getLogger(ZutatJpaFacade.class.getName()).log(Level.SEVERE, null, ex);
        }
    }

    public void edit(kochstudio.entity.Zutat zutat){
        try {
            zutatJpaController.edit(zutat);
        } catch (NonexistentEntityException ex) {
            Logger.getLogger(ZutatJpaFacade.class.getName()).log(Level.SEVERE, null, ex);
        } catch (Exception ex) {
            Logger.getLogger(ZutatJpaFacade.class.getName()).log(Level.SEVERE, null, ex);
        }
    }

    public void destroy(Long id) {
        try {
            zutatJpaController.destroy(id);
        } catch (kochstudio.persistence.exceptions.NonexistentEntityException ex) {
            Logger.getLogger(ZutatJpaFacade.class.getName()).log(Level.SEVERE, null, ex);
        }
    }

    public List<kochstudio.entity.Zutat> findZutatEntities() {
        return zutatJpaController.findZutatEntities();
    }

    public List<kochstudio.entity.Zutat> findZutatEntities(int maxResults, int firstResult) {
        return zutatJpaController.findZutatEntities(maxResults, firstResult);
    }


    public kochstudio.entity.Zutat findZutat(Long id) {
        return zutatJpaController.findZutat(id);
    }

    public kochstudio.entity.Zutat findZutatByName(String name) {
        return zutatJpaController.findZutatByName(name);
    }

    public int getZutatCount() throws RemoteException {
        return zutatJpaController.getZutatCount();
    }
}
```

Ich hoffe man versteht mein Problem. Ich bin nicht der beste im Probleme wiedergeben  :?


----------



## Ice-Tea (23. Jan 2009)

Würde mir folgender Code wieder eine Reference auf das Remote-Object geben? Bzw. brauche ich dann immernoch die Hibernate-Persitenz-Bags auf der Clientseite?

```
public List<kochstudio.entity.Zutat> findZutatEntities() {
        List<kochstudio.entity.Zutat> zutaten = null;
        System.arraycopy(zutatJpaController.findZutatEntities(), 0, zutaten, 0, zutatJpaController.findZutatEntities().size());
        return zutaten;
    }
```
Und vorallem was mache ich mir der einzelden zutat? Da kann ich schlecht ein Array kopieren.


Ich bin für ratschläge wirklich sehr dankbar, denn das ganze ist nicht so einfach zu testen.

Ich habe mir extra ein Subnetz in meinem Heimischen Netz anlegen müssen um sicherzustellen, das nur der RMI Port benutzt werden kann. ( geöffnete Port im seperaten Router )
Daher bin ich dann erst daruf gekommen, das der Client auch Port 1524 öffnet und versucht sich direkt mit der DB zu verbinden. Und noch chlimmer, da der Client die Controller-Klasse nachläd, versucht der Client auf die IP im Subnetz zuzugreifen, was nicht sein darf und auch nicht funktionieren kann.


----------



## byte (23. Jan 2009)

Wenn Du Hibernate Objekte vom Server zum Client weiterreichst, musst Du auf Lazy Loading verzichten. Ansonsten gibts ne LazyInit.Exception, wenn Du auf dem Client (ausserhalb der Hibernate Session) auf die Properties zugreifst. Am besten lädst Du alle Properties auf dem Server vor, bevor Du die Objekte an den Client reichst. Oder Du nullst nicht benötigte Properties vorher (so dass keine Hibernate Collections mehr dahinterliegen).

Wenn Du Dich für Remote Lazy Loading interessiert, dann guck Dir das mal an: http://www.java-forum.org/de/viewtopic.php?t=66958


----------



## Ice-Tea (24. Jan 2009)

Mein Problem liegt wo anders.

Ich hab mal den Client aufein paar zeilen zusammengeschitten um den fehler etwas deutlicher zu machen:


```
SslRMIClientSocketFactory rmiCSF =
                    new SslRMIClientSocketFactory();
            registry = LocateRegistry.getRegistry(
                    server.getHostAddress(), PORT, rmiCSF);

            for(String s : registry.list()){
                System.out.println(s);
            }

            try {
                System.out.println(((ChatFacadeRemote) registry.lookup("ChatFacadeRemote")).getBenutzerAnzahl());
            } catch (NotBoundException ex) {
                Logger.getLogger(RmiClient.class.getName()).log(Level.SEVERE, null, ex);
            } catch (AccessException ex) {
                Logger.getLogger(RmiClient.class.getName()).log(Level.SEVERE, null, ex);
            }
```

Die for-Schleife fukntioniert noch (der client ist also connected), aber sobald ich ein lookup mache, nimmt der Client nicht mehr die öffentliche IP, sondern die lokale IP des Servers (192.168.1.2)

Hier die Ausgabe:

ZutatJpaFacadeRemote
GerichtJpaFacadeRemote
ChatFacadeRemote
24.01.2009 11:44:39 kochstudio.rmi.RmiClient connect
SCHWERWIEGEND: null
java.rmi.ConnectException: Connection refused to host: 192.168.1.2; nested exception is
...

Gibt es eine möglichkeit die Registry an einer Domäne zu binden ohne ein dns aufsetzten zu müssen?

Über google wurde mir schon eine möglickeit aufgezeigt wie ich die Registry an eine bestimmte ip binde (sofern der Host mehrere IP hat). Aber 1. wurde dabei auf SSL verzichtet und 2. ist das auf die lokalenIPs beschränkt.


----------



## Ice-Tea (24. Jan 2009)

Also, solange server+client hinter einer nat sitzten, werde ich einen anderen weg einschlagen müssen.

Ich hab mir den Thread "Lazy Loading" mal angesehen. Leider bin ich nicht so firm in Annostations, daher kann ich die vorgehensweise nicht ganz nachvollziehen. Außerdem ist im augenblick sowieso alles fetchtype.Eager.

Ich habe aber auch schon etwas gefunden, das mir weiterhilft:

RMI behind NAT

Die vorgehensweise eine NAT zu umgehen in dem der Socket offen gehalten wird ist mir bekannt.

Ist es sinnvoll sich an das Beispiel unter dem Link zu halten oder gibt es da schon besser Lösungen?


----------



## Ice-Tea (24. Jan 2009)

Ich :D hat gesagt.:
			
		

> Die for-Schleife fukntioniert noch (der client ist also connected), aber sobald ich ein lookup mache, nimmt der Client nicht mehr die öffentliche IP, sondern die lokale IP des Servers (192.168.1.2)




Ganz kurz und schmerzlos:

```
System.setProperty("java.rmi.server.hostname", "sub.domaene.com");
```

 

Zu dem Link in meinem letzten Post:
Ich werd mal bei Gelegenheit versuchen den Chat, der im moment über den Server läuft, P2P aufzubauen. Mal sehen ob ich es hinkrieg  :bae:


----------



## tuxedo (26. Jan 2009)

@ice-tea

Zum NAt Thema hinter dem Link:

Soweit ich das verstanden habe ist das kein echter Callback: Der Client ruft in einem Serverthread eine blockierende Methode auf. Hat der Server ein "Event" für den Client löst sich die Blockade und der Client holt das Event ab.

Das ist eher ein Event-Listener-Prinzip statt ein "Callback Prinzip".

Funktionier sicher. Aber "effizient" finde ich das nicht. Irgendwo am Server werden hierfür dann wieder Threads benötigt was die Sache mit "1 Thread pro verbundenen Client" wieder näher rücken lässt.

RMI benutzt AFAIK bei echten Callbacks eine neue Verbindung die vom Server zum Client geöffnet wird. Und genau da hapert's mit der NAT...

Gruß
Alex


----------

