[JAVA]Servlet e synchronized

[osa]

Salve ho creato una servlet, dentro la quale c'è un blocco synchronized su un oggetto (un campo della classe).
Ecco il codice:

Object mutex=new Object();
synchronized(mutex){
if ( cond == true){
Thread t=new ExecuteThred(); //è un thread da me creato
t.start(); 
}
}

Voglio che sotto determinate condizioni una sola istanza delle servlet in esecuzione crei il thread (ci deve essere in esecuzione un solo thread ExecuteThread ).
Voglio chiedervi se il "mutex" devo dichiarlo come campo della classe (private Object mutex) o tale oggetto deve essere sostituito con ExecuteThread().
Grazie.

[PGI-Bis]

Premetto che se l'applicazione non è distributable, il server usa una sola istanza della classe servlet per rispondere a tutte le richieste (SRV2.2).

Un blocco sincronizzato su un monitor non condiviso equivale ad un blocco non sincronizzato. Non essendo il monitor condiviso non è infatti possibile che due Thread se lo contendano.

Una variabile locale non è condivisa per definizione.

Dunque questo:

metodo() {
    Object monitor = new Object();
    synchronized(monitor) {
        fai qualcosa
    }
}

equivale a:

metodo() {
    fai qualcosa;
}

Se il monitor è condiviso allora la sincronizzazione stabilisce una mutua esclusione tra i condividenti. Un campo è condiviso. Dunque:

private final Object monitor = new Object();

metodo() {
    synchronized(monitor) {

    }
}

effettivamente esclude che due Thread possano entrare nel blocco in contemporanea.

Occhio che se cond è un campo delle istanze della tua servlet allora esiste la possibilità che siano creati più ExecutorThread.

[osa]

Originariamente inviato da PGI-Bis

Premetto che se l'applicazione non è distributable, il server usa una sola istanza della classe servlet per rispondere a tutte le richieste (SRV2.2).

Un blocco sincronizzato su un monitor non condiviso equivale ad un blocco non sincronizzato. Non essendo il monitor condiviso non è infatti possibile che due Thread se lo contendano.

Una variabile locale non è condivisa per definizione.

Dunque questo:

metodo() {
    Object monitor = new Object();
    synchronized(monitor) {
        fai qualcosa
    }
}

equivale a:

metodo() {
    fai qualcosa;
}

Se il monitor è condiviso allora la sincronizzazione stabilisce una mutua esclusione tra i condividenti. Un campo è condiviso. Dunque:

private final Object monitor = new Object();

metodo() {
    synchronized(monitor) {

    }
}

effettivamente esclude che due Thread possano entrare nel blocco in contemporanea.

Occhio che se cond è un campo delle istanze della tua servlet allora esiste la possibilità che siano creati più ExecutorThread.

Quindi Object mutex devo dichiarlo come campo. La condizione "cond" è la seguente t.getstate().TERMINATED, dove t è un oggetto ExecuteThread, ovvero controllo che il thread sia terminato, in caso affermativo ne avvio un altro, la cosa importante è che ci sia solo un thread ExecuteThread in esecuzione. L'oggetto t è un campo della classe. Però non capisco, da quello che mi hai detto, perchè se la condizione è un campo possono essere creati più thread.

[PGI-Bis]

L'unica cosa che devi assicurare è che la condizione usata per "capire" se esista già un ExecutorThread permanga a prescindere dal numero di istanze della servlet che sono create.

Le specifiche garantiscono l'esistenza di una sola istanza di quella servlet in un certo istante. Non vietano che quell'istanza sia di volta in volta rigenerata.

Ad esempio se dicessimo:

class Servlet... {
    private final Object monitor...
    private final AtomicBoolean condition = new AtomicBoolean(false);

    ...servizio
        if(condition) {
             crea un ExecutorThread, condition.set(false);

Ci fregheremmo con le noste mani. Qui condition è false ma solo per l'istanza corrente di Servlet. Se il server rigenerasse questa istanza allora l'esecuzione del servizio troverebbe condition a true e creerebbe un secondo ExecutorThread.

A conti fatti la questione è un semplicemente di "ambito di vita". Devi far sì che la conzione appartenga ad un ambito superiore a quello di esistenza dell'istanza servlet. Perchè è questo solo il "problema": il ciclo di vita di questi oggetti è determinato esternamente al programma che hai per le mani.

Tutto qua.

[osa]

Originariamente inviato da PGI-Bis

L'unica cosa che devi assicurare è che la condizione usata per "capire" se esista già un ExecutorThread permanga a prescindere dal numero di istanze della servlet che sono create.

Le specifiche garantiscono l'esistenza di una sola istanza di quella servlet in un certo istante. Non vietano che quell'istanza sia di volta in volta rigenerata.

Ad esempio se dicessimo:

class Servlet... {
    private final Object monitor...
    private final AtomicBoolean condition = new AtomicBoolean(false);

    ...servizio
        if(condition) {
             crea un ExecutorThread, condition.set(false);

Ci fregheremmo con le noste mani. Qui condition è false ma solo per l'istanza corrente di Servlet. Se il server rigenerasse questa istanza allora l'esecuzione del servizio troverebbe condition a true e creerebbe un secondo ExecutorThread.

A conti fatti la questione è un semplicemente di "ambito di vita". Devi far sì che la conzione appartenga ad un ambito superiore a quello di esistenza dell'istanza servlet. Perchè è questo solo il "problema": il ciclo di vita di questi oggetti è determinato esternamente al programma che hai per le mani.

Tutto qua.

Prima di tutto grazie per le informazioni. Ora ti spiego la servlet in questione nel suo metodo init() crea un oggetto ExecuteThread, nel metodo post() io controllo se il suddetto thread, per qualche motivo è terminato (il thread è un loop, non dovrebbe terminare) e in tal caso lo riavvio. Il server non crea una sola istanza di una servlet e vengono generati dei thread che eseguono i metodi post, get, ecc della medesima istanza?

[PGI-Bis]

Nì. Cioè sì ma bisogna stare attenti a quell'unico.

E' unica nel senso che il server non crea dieci servlet e poi distribuisce alla prima servlet libera il compito di rispondere ad una richiesta.

Cioè non ci sono più servlet che gestiscono contemporaneamente richieste plurime.

Non è unica nel senso di identica. Il server può rimuovere l'istanza che sta usando. Ad esempio dopo un certo periodo in cui non siano arrivate richieste. Quando sarà necessario, il server creerà una nuova istanza della servlet.

Ecco perchè dico, attenzione al campo. Il campo in quanto tale è vincolato all'istanza. Se l'istanza cambia, la nuova avrà il suo nuovo campo, coi suoi diversi valori.

Probabilmente una soluzione sarebbe quella di assicurare la morte del thread nel metodo destroy() della servlet. Ma non sono sicuro perchè le specifiche non sembrano vincolare l'esecuzione del metodo init() di una servlet all'esecuzione del metodo destroy() dell'istanza precedente.

Io ho parlato di esistenza della servlet ma le specifiche parlano di uso dell'istanza della servlet.

Insomma, per farla breve, usa un attributo del contesto. Nel metodo init verifichi se esiste un Esecutore. Se non c'è lo crei e lo avvii. Nel metodo service verifichi se l'esecutore sia ancora attivo. Se non lo è lo rigeneri. E sei in una botte di ferro.

[alphacygni]

Originariamente inviato da osa

Il server non crea una sola istanza di una servlet e vengono generati dei thread che eseguono i metodi post, get, ecc della medesima istanza?

si, esattamente... infatti se dichiari variabili d'istanza in una servlet hai qualche LEGGERO problema di concorrenza

Pero' non e' detto che l'istanza resti la stessa finche' non "ammazzi" il server...

ma quindi in sostanza a te serve che la servlet ti assicuri di essere "monothread" oppure non ho capito una fava?

[osa]

Originariamente inviato da alphacygni

si, esattamente... infatti se dichiari variabili d'istanza in una servlet hai qualche LEGGERO problema di concorrenza

Pero' non e' detto che l'istanza resti la stessa finche' non "ammazzi" il server...

ma quindi in sostanza a te serve che la servlet ti assicuri di essere "monothread" oppure non ho capito una fava?

Praticamente nella servlet c'è il controllo i mutua esclusione che verifica se ExucuteThread è terminato in tal caso lo riavvia. Ci deve essere solo un thread ExecuteThread in esecuzione. Questo codice mi garantisce ciò?

private Object mutex;
private ExecuteThread t;

......

synchronized(mutex){
if ( t.getState().TERMINATE){
Thread t=new ExecuteThred(); //è un thread da me creato
t.start(); 
}
}

[PGI-Bis]

No. 2, la vendetta.

[osa]

Originariamente inviato da PGI-Bis

No. 2, la vendetta.

Scusa non avevo letto il post da te scritto.
Se la servlet è rigenerata, l'evantuale thread ExucuteThread in esecuzione non dovrebbe terminare o sbaglio?

Tu mi hai scritto:

Insomma, per farla breve, usa un attributo del contesto. Nel metodo init verifichi se esiste un Esecutore. Se non c'è lo crei e lo avvii. Nel metodo service verifichi se l'esecutore sia ancora attivo. Se non lo è lo rigeneri. E sei in una botte di ferro.

Non ho capito come posso verificare, nel metodo init, che l'Esecutore è attivo se uso un attributo di contesto invece di un campo.

Ciao e grazie.

[PGI-Bis]

Una volta lanciato il Thread fa storia a sè. Con o senza la servlet, quello continua a girare. E, a meno che il gruppo di appartenza non sia particolare, continuerà a farlo finchè la macchina virtuale non sarà ammazzata con un kill. O finchè il suo compito non termini ma questo dipende da cosa c'è nel run e da eventuali invocazioni esplicite del metodo interrupt() se la condizione di interruzione sia gestita nel run().

init.

Nell'init verifichi con:

Object o = getServletContext().getAttribute("esecutore");
if(o == null) {
   non c'è: crealo, attivalo e registralo come attributo
} else if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    if(t non è attivo...) { attivalo }
}

Nel service lo recuperi con lo stesso sistema:

Object o = getServletContext().getAttribute("esecutore");
if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    eccetera
} else {
    grande magagna!
}

E' la stessa cosa che hai già fatto solo che anzichè essere un campo della tua servlet, l'esecutore è un attributo del contesto delle servlet. Siccome il contesto è unico e persistente (rispetto al ciclo di vita di una servlet) l'esecutore, una volta creato, si comporta come un singleton.

[PGI-Bis]

Ps: se poi anzichè nell'init della servlet crei l'esecutore con un ServletContextListener allora sei proprio EE. Very Java EE .

[osa]

Originariamente inviato da PGI-Bis

Una volta lanciato il Thread fa storia a sè. Con o senza la servlet, quello continua a girare. E, a meno che il gruppo di appartenza non sia particolare, continuerà a farlo finchè la macchina virtuale non sarà ammazzata con un kill. O finchè il suo compito non termini ma questo dipende da cosa c'è nel run e da eventuali invocazioni esplicite del metodo interrupt() se la condizione di interruzione sia gestita nel run().

init.

Nell'init verifichi con:

Object o = getServletContext().getAttribute("esecutore");
if(o == null) {
   non c'è: crealo, attivalo e registralo come attributo
} else if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    if(t non è attivo...) { attivalo }
}

Nel service lo recuperi con lo stesso sistema:

Object o = getServletContext().getAttribute("esecutore");
if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    eccetera
} else {
    grande magagna!
}

E' la stessa cosa che hai già fatto solo che anzichè essere un campo della tua servlet, l'esecutore è un attributo del contesto delle servlet. Siccome il contesto è unico e persistente (rispetto al ciclo di vita di una servlet) l'esecutore, una volta creato, si comporta come un singleton.

Grazie sei stato di grande aiuto.

[osa]

Perdonami in init() io verifico se esisteva il Thread nel contesto, altrimenti lo setto com this.getServletContext().setAttribute(...) , in questo modo il contesto vive anche se la servlet è rigenerato se ho capito bene o erro?

[PGI-Bis]

Sì. Il ciclo di vita del contesto (ServletContext) è più ampio di quello delle servlet. E' legato a quello dell'applicazione web. Parte quando l'applicazione è dispiegata sul web server e termina quando l'applicazione schiatta.