# RMI und Db4o



## Ralf Ueberfuhr (21. Okt 2005)

Hallo,

Ich haben eine Client/Server-Anwendung über RMI und speichere die Daten mit Db4o. Nun habe ich aber das Problem, dass z.B.

Db4o für die set()-Funktion (UPDATE) die Original-Referenz benötigt. Wenn ich den Befehl per RMI gebe, gehen dabei aber die Referenzen verloren.

Z.B:

1. Client fragt nach Benutzerdaten  per RMI, erhält ein Objekt
2. Benutzerdaten werden geändert und sollen abgespeichert werden. Per RMI wird die objectContainer.set(...)-Funktion aufgerufen, es kommt aber nicht die unter 1. geladene Referenz an, sodass das Objekt als ein neues gespeichert wird, was 2 Objekte zur Folge hat.

Was kann ich da machen?

_Ich weiß, dass ich auch die Client/Server-Funktionen von Db4o nutzen kann, aber das soll nicht geschehen. Die Kommunikation sollte schon über RMI laufen._

_Ich habe auch schon sowas wie ne ID eingeführt, die beim GET oder INSERT gesetzt wird (Db4o-interne ID) und beim UPDATE und DELETE verwendet wird, aber das Problem besteht bei strukturierten Objekten, wo das dann schon nicht mehr so einfach anwendbar ist._

*Gibt es per RMI die Möglichkeit, Referenzen, die vorher rausgegeben wurden, später wieder zu verwenden?*
*Gibt es bei Db4o die Möglichkeit, nicht die Referenzen zu vergleichen, sondern spezielle Felder der Klassen?*


----------



## Bleiglanz (21. Okt 2005)

überschreiben deine Objekte "equals"?

ggf. mal nachlesen, wie db4o die "Objektidentität" handhabt, ist das wirklich so, dass da == verwendet wird??


----------



## Ralf Ueberfuhr (21. Okt 2005)

equals überschreiben sie, aber das wäre eh verkehrt, wenn z.B.

Ein User-Objekt equals über die getName()-Eigenschaft prüft, jedoch ein Benutzer umbenannt werden soll.

Im db4o-Tutorial steht, dass die Referenz da sein muss, wie sie beim Laden (SELECT) oder Einfügen (INSERT) erzeugt wurde. Sonst wird das Objekt immer neu angelegt.


----------



## Bleiglanz (21. Okt 2005)

dann bleibt dir wohl nur die Möglichkeit, am Server die Referenz vorzuhalten

der Client schickt ein Objekt

du kannst (irgendwie? ID-Map??) entscheiden, welches schon existierende Objekt gemeint ist

und dann gibts ne "update" Methode

User#updateFromOther(User other)

die die geänderten Daten in dein "richtiges" hineinkopiert


----------



## Gast (21. Okt 2005)

Die Referenzen beim Server zu halten ist aber nicht so empfehlenswert, weil bei mehreren Clients der verbrauchte Speicher einfach zu groß ist. Und beim Abmelden die Referenzen zu löschen kann auch schiefgehen, wenn die Verbindung mal abbricht.

Naja, ich werd wohl doch die Client/Server-Funktionen von db4o nutzen, denn da klappt es seltsamerweise.


----------



## Ralf Ueberfuhr (21. Okt 2005)

Das eben war ich. Danke erstmal.


----------



## Guest (22. Okt 2005)

Wenn die serialisierbaren Objekte eine eindeutige ID besitzen, dann kannst du mit Hilfe der Methode
	
	
	
	





```
Object readResolve() throws ObjectStreamException;  // siehe dazu die Doku zu java.io.Serializable
```
sicherstellen, dass serverseitig die richtige Referenz verwendet wird.


----------



## Ralf Ueberfuhr (22. Okt 2005)

Hab mich darüber schlau gemacht. Das bedeutet aber, dass ich auf dem Server entweder die Instanzen in einer Hashtable speichern oder stets neu aus der Datenbank laden muss, richtig?

Ersteres überfordert meiner Speicherplatz, wenn ich nicht in Intervallen "aufräume", Letzteres erfordert stets einen Speicherzugriff mehr. Dann muss ich mir einen Kompromiss ausdenken.


----------



## Guest (23. Okt 2005)

masseur81 hat gesagt.:
			
		

> Hab mich darüber schlau gemacht. Das bedeutet aber, dass ich auf dem Server entweder die Instanzen in einer Hashtable speichern oder stets neu aus der Datenbank laden muss, richtig?


Eher das zweite. Also aus der Datenbank neu holen.
Im Prinzip würde ich aber die Methode mit den ValueObjects, die Bleiglanz vorgeschlagen hat, vorziehen.
Es ist einfach besser und ist die übliche Vorgehensweise.


			
				masseur81 hat gesagt.:
			
		

> Ersteres überfordert meiner Speicherplatz, wenn ich nicht in Intervallen "aufräume", Letzteres erfordert stets einen Speicherzugriff mehr. Dann muss ich mir einen Kompromiss ausdenken.


Früher oder später wird das ganze immer komplizierter. Insbesondere in einer 
Mehrbenutzerumgebung, wo Transaktionssicherheit gefragt ist, wäre 
ein Application Server die bessere Wahl.


----------



## Ralf Ueberfuhr (24. Okt 2005)

Danke für die Antwort. Ich habe jetzt erstmal eine Klasse mit ner Id und einer copyTo-Methode als Oberklasse für alle persistenten Objekte erstellt. Mithilfe von Java Reflection kann ich es auch ermöglichen, strukturierte Objekte (also ein persistentes Objekt in einem anderen referenziert) umzusetzen.

Auf dem Server "cache" ich die Objekte aus der Datenbank für 10 Minuten, um jedesmal ein Laden der Referenz aus der Datenbank zu vermeiden, aber auch um einer riesigen Map mit Referenzen vorzubeugen.

Mit "Application Server" kenn ich mich nicht so sehr aus. Gibt es ein empfehlenswertes Tutorial für nen ersten Einblick? Welchen Application Server empfehlt ihr? (JBoss...)


----------



## Guest (24. Okt 2005)

masseur81 hat gesagt.:
			
		

> ...
> Auf dem Server "cache" ich die Objekte aus der Datenbank für 10 Minuten, um jedesmal ein Laden der Referenz aus der Datenbank zu vermeiden, aber auch um einer riesigen Map mit Referenzen vorzubeugen.


Was ist, wenn gerade innerhalb dieser 10 Minuten viele Anfragen kommen?  :wink: 


			
				masseur81 hat gesagt.:
			
		

> Mit "Application Server" kenn ich mich nicht so sehr aus. Gibt es ein empfehlenswertes Tutorial für nen ersten Einblick? Welchen Application Server empfehlt ihr? (JBoss...)


JBoss ist OK. 
Zur Instllation brauchst du es nur zu entpacken und sicher zu stellen, dass JAVA_HOME gesetzt ist.
Tutorials findest du sicherlich hier unter "Bücher und Tutorials". Mir fällt spontan nichts ein, was
als Einstieg geeignet wäre. Ich kann dir eine Seite empfehlen: www.theserverside.com 
Da findest du alles, was mit der serverseitigen Programmierung zu tun hat.


----------



## Ralf Ueberfuhr (24. Okt 2005)

Ok, danke dir.


----------

