Newsgroup: it.comp.java
Titolo: Liberare le risorse degli attributi di sessione

Implementando un HttpSessionListener speravo di poter fare
un'operazione di questo genere:
public void sessionDestroyed(HttpSessionEvent e)
{
	HttpSession session=e.getSession);
	Connection conn=(Connection)
		session.getAttribute("database_connection");
	try
	{
		conn.close();
	}
	catch(SQLException e)
	{
		System.err.println(e);
	}
}
Invece, ahimè, scopro che se quando sessionDestroyed viene chiamato la
session ha già perso il bind agli attributi...
C'è un workaround?

 C'è un workaround?
Mi sembra probabile che se tu hai bisogno di un attributo in quel momento,
probabilmente sia qualcosa che non ha un senso solo a livello di Session, ma
di contesto! Ad esempio, tu indichi una Connection JDBC, ma memorizzare in
una sessione utente la connessione non è certo la migliore soluzione! Di
solito gli application server ti forniscono un pool di connessioni
accessibile ad esempio con una query JNDI e l'accesso ad un oggetto
DataSource: è proprio indispensabile, tenere aperta una connessione per
tutta la durata della sessione web? E' un totale anti-pattern! Per altri
esempi, appunto, se è qualcosa che non ha senso a livello di utente, ma di
contesto, puoi inserire gli attributi nel ServletContext: se si tratta
invece di risorse che "vanno" liberate alla scadenza della sessione, forse
il tuo non è il design ideale.
Comunque, ora che ci penso, non è vero, che gli attributi si perdono prima
della scadenza della sessione! La specifica non mi pare che lo dica, ed in
effetti se guardi il metodo "expire" di StandardSession in Jakarta Tomcat
(qua
http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org
/apache/catalina/session/StandardSession.java?rev=1.13&content-type=text/vnd
.viewcvs-markup ) vedi chiaramente che il listener riceve l'evento e solo
poi vengono buttati gli attributi. Che server usi?

poi vengono buttati gli attributi. Che server usi?
Uso Tomcat 4.0 e se faccio
public void sessionDestroyed(HttpSessionEvent e)
{
	try
	{
		Enumeration attributeNames=
			e.getSession().getattributeNames();
	}
	catch(IllegalStateException x)
	{
		System.err.println(x);
	}
}
mi stampa: 
java.lang.IllegalStateException: getAttributeNames: session already
invalidated.

 invalidated.
In effetti il codice a cui facevo riferimento io fa parte del codebase
di Tomcat 5.0: pare che la specifica 2.4 dica chiaramente che gli
attributi devono essere ancora validi, a quel punto, ma con Tomcat 4.0
hai la specifica 2.3 e quindi...
Domanda: ma sei sicuro che il tuo approccio sia inevitabile?
Domanda 2: se proprio vuoi fare quello che stai facendo, non puoi fare
un oggetto wrapper che
incapsuli la connessione, implementando l'interfaccia per cui riceve una
notifica quando viene unboundato dalla sessione, e a
quel punto chiude la connessione?
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Mi spiego meglio, perché mi rendo conto di non essere stato molto chiaro...
Intendo dire: uno stratagemma per non subire il problema dell'invalidazione
della sessione č di fare il binding come attributo non dell'oggetto
Connection stesso, ma di un oggetto "incapsulatore" che implementi
l'interfaccia HttpSessionBindingListener e contenga l'oggetto connection
come attributo: quando riceve il "valueUnbound" chiude la connessione. E'
comunque una soluzione scorretta, dal mio punto di vista, ma dovrebbe
funzionare nel modo in cui te lo aspetti. Un'alternativa puň essere
implementare l'interfaccia HttpSessionAttributeListener, dai un'occhiata
alla specifica.