Diesmal frage ich gleich vorher, bevor sich eine fixe Idee von mir als gar nicht realisierbar erweist, so wie die Idee mit den dynamischen Methodenaufrufen aus einem Array...
Sind ObjectOutputStream/ObjectInputStream fest an zwei Threads/Objecte gebunden?
Meine Idee
Mehrere Threads tauschen ueber ObjectOutputStream/ObjectInputStream Daten mit einem Object aus.
Java:
//fix , erzeuge einmal ein Object vom Typ onlyModel auf dass dann alle Thread "zugreifen"
onlyModel myModel =newonlyModel(objectINs, objectOUTs);...//schleife jeder Client bekommt einen Thread
aSocket = myServerSocket.accept();
tcpServerThread aThread =newtcpServerThread(aSocket, objectINs, objectOUTs);
ich musste schon streams zwischen zwei threads realisieren.
jetzt kann ich die klassen mit wenig aufwand einfach umbauen und in meine serveranwendung kopieren.
wobei, irgendwie finde ich die streamgeschichte unnötig, würde man doch im "realen leben" immer über eine referenz auf das object machen und die methoden dann synchronized oder?
EDIT:
oh ich merke gerade jeder Thread muss dem Model Object ja mitteilen "wer er ist" sonst kann das Model nicht ueber den passenden ObjectOutputStream zurück schreiben.
wobei, irgendwie finde ich die streamgeschichte unnötig, würde man doch im "realen leben" immer über eine referenz auf das object machen und die methoden dann synchronized oder?
Welche Methode? Die setX Methode? Hängt davon ab was man möchte und wie es implementiert ist.
Generell ist es ungünstig Objekte innerhalb des eigenen Programms zu serialisieren um sie an anderer Stelle wieder zu deserialisieren. Alles Overhead...
@Wildcard:
oh, wenn ich deinen Post lese, bemerke ich dass mir wohl die eine oder andere "Grundinformation" fehlt.
Mit serialisieren meinst Du jetzt das Verwenden von Streams oder?
Man nennt es doch auch noch Object, wenn ich noch andere Methoden ausser getX() / setX() habe,oder?
In meinem Fall beinhaltet die Klasse Methoden zum entgültigen Speichern von Daten in einer Datei.
@Wildcard:
oh, wenn ich deinen Post lese, bemerke ich dass mir wohl die eine oder andere "Grundinformation" fehlt.
Mit serialisieren meinst Du jetzt das Verwenden von Streams oder?
Das Erklärt mir trotzdem nicht warum du ObjectInput/OutputStream zur inter-Threadkommunikation verwenden willst anstatt einfach eine Referenz zu übergeben (und die dann gegebenfalls per ObjectOutputStream zu serialisieren).
Im übrigen ist ein ObjectOutputStream kein Ersatz für eine Persistenzschicht weil es viel zu unflexibel ist und an interne Datenstrukturen gekoppelt ist.
Wenn das was ernsthaftes ist, speicher lieber in einem neutraleren Format. Serialisierung ist primär wichtig für RMI, Clipboard, inter-process Kommunikation,...
Die Idee der ObjectStreams entstand durch eine vorangegangen Vorgabe der Aufgabenstellung.
Ich habe die Idee jetzt aber endgültig verworfen, schon alleine weil es ohne weniger Aufwand bedeutet. Ich dachte ich koennte bereits vorhanden Code fix abaendern.
