Hej;
Jeg har lige brugt timer på et problem med, at ændringer i et hashtable i
en serializable klasse, der via en ObjectOutput stream blev sendt til en
klient via en TCP socket, tilsynelade ikke blev modtaget af klienten.
Klienten modtog disse requests således:
IResponse rsp = (IResponse)aSockIn.readObject();
Den serialiserbare klasse indholdt (bl.a.) en vektor af hashtables, der
blev tilføjet til vektoren således:
vec.add( ( (CSession)sml.nextElement() ).getProfile().getCriteriaMap() );
Uden at gå i detaljer returnerer getCriteriaMap() en reference til det
hashtable, der skal indgå i response-pakken.
OK det for mig lettere mystiske er så, at når det hashtable
getCriteriaMap() returnerer er blevet modificeret og jeg i en debugger
kunne se, at det VAR de nye værdier der var i hashtablet lige før det blev
sendt som en del af response-klassen over ObjectOutputStream'en, så var det
stadig det gamle hashtable der blev modtaget på klienten. Som desperationen
satte ind prøvede jeg til sidst (efter mistanke om, at det havde noget med
referencer at gøre) at sende en clone af response objektet afsted istedet:
vec.add( ( (CSession)sml.nextElement()
).getProfile().getCriteriaMap().clone() );
Og, jamen, så virkede det jo pludselig... Det jeg så gerne vil høre er,
hvad der egentlig foregår her. ;) Er det noget med, at fordi det er samme
instans af hashtablet jeg serialiserer igen, så mener klienten at den
allerede HAR en reference til den instans, og dermed bruger de gamle
værdier, selv om der er sket ændringer i objektets tilstand der, hvor jeg
serialiserer det? Kan den godt se, at det er samme instans (via et
hemmeligt objekt-ID eller sådan noget)?
Nå, men det var da også en måde at bruge en aften på... ;)
/\/\\ads Orbesen Troest
|