Socket Object wird scheinbar falsch empfangen

[OMGITM]

Hallo,

habe ein kleines Problem beim verschicken eines Objectes über einen String. Und zwar möchte ich ein Artikel object verschicken, folgendermaßen:

// erg ist ein Artikel Object
try {
System.out.println("Artikel: \n \n" + erg + "\n \n" + geschickt");

objoutStream.writeObject(erg);
objoutStream.flush();

} catch (IOException e) {	System.err.println(e); }

der print ergibt:

Artikel:
Name: Bild
Anzahl: 100
Art-Nummer: 10

geschickt

Empfangen wird via:

Artikel a = null;
a = (Artikel) objinStream.readObject();

Wenn ich mein Programm starte, den Artikel empfangen will, ohne irgendwas gemacht zu haben läuft alles glatt.

Wenn ich allerdings starte, mir den Artikel hole, wieder zurück schicke diesmal mit einem int zusammen, diesen int dann als Anzahl setze und dann den Artikel wieder hole, wird das scheinbar das alte Artikel object empfangen.


Nochmal bisl anschaulicher:

Client: Suche Artikel (Schicke ident. String)
Server: Artikel gefunden: Schicke Artikel-Object
Client: Empfange Artikel und print
Client: möchte ein Attribut des Artikels ändern (anzahl)
Client: Schicke Artikel + neue Anzahl int
Server: Empfange Artikel + int
Server: Setze neue Anzahl und schicke geändertes Object
Client: Empfange Object und print

Bei diesem letzten Schritt ist der Fehler: das Object hat noch den alten Wert für die Anzahl.


Habe mit print und debug geprüft: Es wird definitiv das object mit den richtigen Daten verschickt, aber das mit den falschen empfangen.

Woran kann das liegen?

 

[Spacerat]

Da kann man nur Vermutungen anstellen. Evtl. gibst du ja blos den falschen Artikel aus (erg statt a).

Hoffentlich ist das Ganze nur 'ne Übung für Serializable, sonst würde ich mir um das Design noch mal ernsthaft Gedanken machen.
Begründung:
1. Für solche "Verwaltungen" eignet sich SQL. Eine DB dazu kann man immer noch selbst entwickeln, wenn man Zeit hat, ansonsten bietet sich JDBC mit MySQL an.
2. Immer ganze Objekte über den Stream zu schicken, kann auf Dauer zu sehr viel Traffic führen. Wenn das ein Objektspeicher oder eine Datenbank für Online-Spiele oder Shops werden soll, wirst du damit nicht viele Kunden werben können. Schon gar nicht die, die evtl. 5GB UMTS-Volumenbegrenzung haben.
3. Wenn man schon die Objekte hin und her schaufelt, dann sollten zumindest Client und Server dazu in der Lage sein, Objektattribute zu ändern, statt zusätzlichen Datenverkehr für die zu ändernden Daten zu fabrizieren.
4. Das sind blos gut gemeinte Tips. Nicht beleidigt sein, wenn's überheblich klingt. Wart' erst mal ab, wenn dir andere User Vorschläge zu "Clean Code" machen.

 

[OMGITM]

moin,

ist nur eine Übung zu Sockets. Ist eine E-Shop Übung, also Traffic egal.

Es wird definitiv das richtige Objekt verschickt. Ich habe die Zeile zum verschicken mal auskommentiert. Und dann alles genauso ausgeführt. Auf Clientseite wurde dann auf ein vom Server verschicktes Obeject gewartet und das Programm läuft nicht weiter, solange das Object nicht kommt (ist auch richtig so).

Zweiter Test war ein print vor und nach dem abschicken (Client & Serverseite).

Serverseite: Gibt das Object mit den richtig geänderten Daten raus (vor und nach dem schicken).

Clientseite: Object existiert vorm empfangen nicht - nach dem Empfangen hat es die falschen Daten.

Ich bin ratlos.
Das empfangene Object wird mit dem Empfangen erstellt und ist ganz sicher nicht irgendein schon vorhandenes.

Kann es denn sein, dass beim verschicken irgendein Puffer noch gefüllt ist und er somit das falsche Object verschickt?

 

[SlaterB]

einen Puffer gibt es in der Tat, mit reset() auf Sendeseite könnte das Problem verschwinden

genauere Details wären interessant,
wenn der Server den Artikel zurückgebekommt, ob mit int darin oder separat, dann ist dieses Artikel-Objekt B sicherlich != dem zu Beginn gesendeten A?
nachprüfen kannst du das, indem du den ersten merkst, was anscheinend eh der Fall sein muss, und eben einen Vergleich ausführst,

nun die Frage, was sendet der Server beim zweiten Mal? das eben empfangene B oder das alte A?
A ist im ObjectOutputStream-Cache, da würde also eine int-Änderung nicht auffallen,
also auf Server-Seite schon, das Objekt existiert nur einmal im Speicher,
aber der ObjectOutputStream schicht an den Client nur die minimale Nachricht 'nochmal Objekt A',
welches der Client im Originalzustand auch in seinem Cache hat

genauso nachprüfbar ist nun der zweite Empfang beim Client:
beim Cache wäre das zweite empfange Objekt exakt dasselbe wie das erste,
hast du dir das gemerkt, dann könntest du wieder mit == vergleichen und das bestätigen

 

[Spacerat]

@SlaterB: Wie, das geht? Ich hatte vor langer Zeit mal ein ähnliches Problem, als ich Teile einer Baumstruktur serialisieren wollte. Beim deserialisieren hätte mir der ObjectStream dann doch eigentlich identische Objekte, statt neuen Instanzen von bereits gelesenen Knoten liefern müssen. Das wäre dann das vom TO gewünschte verhalten des ObjectStreams, während ich es so benötigen würde, wie es gerade beim TO läuft. Hast du mal 'nen Link, wo dieses Verhalten etwas genauer unter die Lupe genommen wird?

 

[SlaterB]

einfach was selber zusammenstellen, an Code kann man jeweils am besten erkennen/ erklären was gewünscht ist und was passiert,

mit 'objectstream java cache' lande ich aber gerade bei
[JavaSpecialists 088] - Resetting ObjectOutputStream
das dürfte wohl alles abdecken,


vielleicht auch noch
[JavaSpecialists 166] - Serialization Cache
(2. Suchergebnis) nicht genau nachgeschaut

 

[OMGITM]

einen Puffer gibt es in der Tat, mit reset() auf Sendeseite könnte das Problem verschwinden

Gold Tipp! Das ich da nicht selber drauf gekommen bin! Klappt. Weiß zwar nicht genau woran es lag, aber mit einem reset des ObjectOutputStream vor dem senden klappts!! Habe das reset mal vor jedes senden gesetzt.

Dachte das mit flush der ganze Puffer immer raus geschrieben wird... Das flush hatte ich nämlich nach jedem Senden!


Mache heute Nachmittag mal ein paar weitere, ausführliche Tests.