[java-servlet] ambito delle variabilii

[prazision]

public class MioFilter implements Filter {

private FilterConfig filterConfig = null;
private String h;
public void init(FilterConfig filterConfig) throws ServletException
{
this.filterConfig = filterConfig;
}

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException
{
HttpServletRequest request=null;
HttpServletResponse response=null;

request = (HttpServletRequest)req;
response = (HttpServletResponse)res;

h=(String)request.getParameter("a");
for(int y=0;y<100000;y++){

System.out.println(y+" "+h);
}
chain.doFilter(request,response);

}

public void destroy()
{
filterConfig = null;
}
}


se uno si crea un filtro(o anche una servlet) e utilizza una variabile di classe(come nel mio caso la stringa h)ho notato che accade che tale variabile (sotto tomcat) viene condivisa da tutti i thread che richiamano tale filtro(o nel caso di una servlet la servlet).
cio' (penso) perchè la servlet (o il filtro) istanziata da tomcat è una sola e funziona in multithreading.
per ovviare a questa cosa(che potrebbe causare evidenti danni) conviene dichiarare direttamente le variabili dentro i metodi, giusto???(oppure sincronizzare il codice ma mi sembra eccessivo)

grazie

[kingv]

l'istanza puo' essere una sola oppure un numero ristretto, a seconda dell'application server che usi ma come hai evidenziato si pone un problema nel caso verosimile che piu' thread accedano all'oggetto.


L'uso di variabili locali (passate come parametri nei metodi) è una buon approccio per scrivere codice thread safe. non sincronizzare niente, in questo caso non è un buon approccio ;)

[prazision]

l'istanza puo' essere una sola oppure un numero ristretto, a seconda dell'application server che usi ma come hai evidenziato si pone un problema nel caso verosimile che piu' thread accedano all'oggetto.


mmm io partivo dal presupposto che il mio web-server fosse tomcat che usa un'unica sitanza (su questa cosa ti ho già tirato pazzo un po' di tempo fa :sofico: )


L'uso di variabili locali (passate come parametri nei metodi) è una buon approccio per scrivere codice thread safe. non sincronizzare niente, in questo caso non è un buon approccio ;)


più che variabili locali passate come parametri nei metodi io intendevo dichiarare la variabile proprio all'interno del metodo:

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException
{
...
String h=(String)request.getParameter("a");
...

}

è sbagliato?

grazie (:read: ricordati il mio mini-progettino )

[theClimber]

più che variabili locali passate come parametri nei metodi io intendevo dichiarare la variabile proprio all'interno del metodo:


In generale va benissimo. Pero' la visibilita' della variabile ovviamente risulta limitata al solo metodo.

Pero' c'e' il rischio che diventi una scusa per non partizionare bene la logica ed i metodi del SW; mi e' capitato di dover manutenere codice di servlet che in questo modo avevano metodi di centinaia di righe di codice..... :muro: :muro: :help:

Puoi fare altre 3 cose:

Passare esplicitamente le variabili ad altri metodi (o passare la request e la response stesse)
Costruire nel metodo di servizio della servlet un oggetto, sempre con queti parametri, che esegua poi lui la logica di business.
Utilizzare dei field di tipo ThreadLocal (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html) . In questo modo il valore memorizzato e' relativo al solo thread di esecuzione; se non usi il JDK 1.5 con i Generics, ti troverai pero' a fare un po di operazioni di Down Casting nel recuperare i dati


Quando possibile cerco di usare prevalentemente la scelta 2, con la 1 e la 3 in misura minore. C'e' l'ulteriore beneficio di aver spostato la logica di esecuzione in una classe che non e' una servlet, quindi non dipende dal container, ed e' quindi piu' facilmente riutilizzabile e testabile.

[kingv]

In generale va benissimo. Pero' la visibilita' della variabile ovviamente risulta limitata
Puoi fare altre 3 cose:

Passare esplicitamente le variabili ad altri metodi (o passare la request e la response stesse)





intendevo esattamente questo, anche se è una soluzione spesso inelegante (ma il codice che si scrive dentro una servlet è poco "a oggetti", di solito).

[kingv]

grazie (:read: ricordati il mio mini-progettino )


mi sono dimenticato :doh:

lo ho da settimane sul piccì dell'ufficio ma non l'ho ancora guardato, scusa

[prazision]

Passare esplicitamente le variabili ad altri metodi


public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException
{
...
altroMetodo((String)request.getParameter("a"));
...

}


Costruire nel metodo di servizio della servlet un oggetto, sempre con queti parametri, che esegua poi lui la logica di business.


public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException
{
...
NuovoOggetto ogg= new NuovoOggetto ((String)request.getParameter("a"))
ogg.metodo();
...

}


sono questi i 2 modi che intendi giusto??

già che ci sei mi dici una cosa che non ricordo mai.
quando si dice ' campi di una classe' si intendono solo le variabili di quella classe o le variabili+ i metodi?

grazie

[prazision]

mi sono dimenticato :doh:

lo ho da settimane sul piccì dell'ufficio ma non l'ho ancora guardato, scusa


fa nulla, figurati non ti preoccupare, io ho 1000 cose da fare , se anche lo guardi fra 3 anni per me è uguale(per la verità fra 3 anni spero di essere ai caraibi al sole e non a lavorare :D )

[theClimber]

non sincronizzare niente, in questo caso non è un buon approccio ;)

Da non fare perche' equivarrebbe a far eseguire un Thread/Richiesta alla volta, mettendo in coda tutti gli altri.

Questa non e' una buona cosa da farsi in una servlet, dat che richieste multiple possono essere parallelizzate in modo efficace in quanto hanno una parte dignificativa di IO di lettura e scrittura sugli stream.

Le performance come tempi di risposta. capacita' di carico e scalabilita' del server ne risulterebbero compromesse.

[theClimber]

sono questi i 2 modi che intendi giusto??

già che ci sei mi dici una cosa che non ricordo mai.
quando si dice ' campi di una classe' si intendono solo le variabili di quella classe o le variabili+ i metodi?

grazie

Esatto.

Con campi ('fields' in inglese) si intendono solo le variabili (ed in genere quelle non statiche se non specificato altrimenti)


intendevo esattamente questo, anche se è una soluzione spesso inelegante (ma il codice che si scrive dentro una servlet è poco "a oggetti", di solito).


vero, per questo preferisco mantenere la servlet piu' semplice possibile, che si occupi solo di cose da servlet (e.g. recuperare dati da request/response, scrivere nella response o forwardare verso la View). Il problema piu' grave cmq e' la maggior difficolta' a scrivere test unitari, dato che e' difficile/noiso ricostruire gli oggetti Request/Response quando si eseguono test unitari all'esterno del container. Se proprio e' indispensabile si puo' risultare utile il progetto MockObjects (http://www.mockobjects.com)

[prazision]

grazie