Newsgroup: it.comp.java
Titolo: dubbio su HttSession.getID()

Il javadoc asserisce che viene generato dal container un ID unico.E fin
qui tutto ok ma mi è sorto un dubbio.
1) nel caso scada una sessione, quella Stringa può essere assegnata ad
una altro client?
2) nel caso di riavvio del Web Application server c'e' pericolo che una
Stringa precedentemente assegnata venga riassegnata?
Il problema si pone nel mio caso dove raccolgo dei dati durante una
sessione e mi interessa capire se appartengono ad un unica sessione.
La mia speranza è che l'ID contenga anche informazioni sull'istante di
creazione dell'ID, questo garantirebbe l'unicità,ma andarsi a guardare
il codice del GlassFish forse è eccessivo.
Voi ci avete mai pensato?
Saluti

Fabiano ha scritto:

Sono proprio maleducato, fate finta che all'inizio abbia scritto:
Saluti a tutti,
 ...
e alla fine:
 ...
Ringrazio
Saluti
ero sovrappensiero

Fabiano ha scritto:

Ciao, non so darti al volo la risposta esatta ai tuoi due quesiti però 
ti suggerirei di prendere in considerazioni il fatto che HttpSession ha 
un metodo getCreationDate() che potresti usare in concomotanza col getID
Ciao

 Ciao
astuto.Terrò in considerazione questa possibilità
Grazie,
ciao
P.S:se qualcuno sa esattamente come lavora getID() mi risparmierebbe
comunque di memorizzare dati inutile. wait()



no.
ma non ho capito dove ti stai andando ad impelagare: tu hai una scatola 
(sessione) dove metti degli oggetti, se in seguito riapri questa scatola 
e tiri fuori due o più oggetti cosa ti fa dubitare che questi oggetti non 
fossero dentro la stessa scatola?

 
salvo le informazioni in modo persistente associate ad un identificativo
  di sessione che presumo unico (i dati vengono salvati e poi elaborati
in seguito.. anche dopo settimane), quello che mi serve è un
identificativo per la sessione che sia davvero unico.
Ad esempio gli oggetti A e B sono stati creati nella sessione S1, gli
oggetti C e D nella sessione S2.
Se risultasse ID_S1=ID_S2 (a causa di un riuso, o di una collisione) al
momento della elaborazione potrei erroneamente concludere che che
A,B,C,D sono oggetti che sono stati creati nella stessa sessione.
Ci sono + modi di risolvere, incrementando un contatore ad esempio e
ripartendo sempre dal valore più grande, ma usare la ID della sessione
sarebbe immediato ed efficiente.. ammesso che funzioni come sperato.

 sarebbe immediato ed efficiente.. ammesso che funzioni come sperato.
Sicuramente ci può essere un riuso. La probabilità di questo dipende 
dall'implementazione.
Se vuoi una chiave puoi anche usare
session.getId() + ":" + session.toString()
o cose simili (data di creazione  eccetera), che rendono il rischio di 
collisione praticamente pari a 0.

 collisione praticamente pari a 0.
grazie a tutti per i vostri interventi, mi avete dato degli spunti utili.
Voglio contribuire con una cosa che ho scoperto, il calcolo della ID è
legata alla implementazione siccome è effettuato dal container, quindi
farci troppo affidamento non è il caso.
Comunque usare il tempo e una costante unica sembra un ottima strada per
generare un ID (anche numerico).
Saluti

 identificativo per la sessione che sia davvero unico.
l'identificativo univoco te lo generi da te con un progressivo, un 
sequence, un timestamp o uno qualsiasi dei mille altri modi possibili.

rootkit ha scritto:

Si sono daccordo, ma ad esempio il timestamp da solo potrebbe non
bastare (ms). Il mio cruccio verteva più che altro sul getID(), capire
l'algoritmo che usava sarebbe stato utile e forse avrebbe risolto il
problema senza scrivere una riga di codice.
Alla fine quello che ho fatto è generare un Long da un contatore unico e
dal tempo.
Grazie per i suggerimenti

Fabiano ha scritto:


Ho usato un termine sbagliato... non intendvo costante unica, ma un
contatore che fornisce lo stesso numero una sola volta per lo stesso
timestamp.