Sappiamo che i bean di sessione senza stato non mantengono lo stato con alcun mezzo. Allora qual è il punto di avere una variabile globale in un bean di sessione senza stato? Perché non è bloccato nelle specifiche (per evitare inutili confusioni)?Qual è il punto di avere una variabile globale in un bean di sessione senza stato?
Se vi sono vantaggi pratici di avere una variabile globale, spiegare con un frammento di codice.
Chiaramente qualsiasi risposta deve indicare che una sessione senza stato EJB non deve tenere lo stato tra le chiamate ai metodi sull'EJB.
Piuttosto che adottare un approccio di linea dura vietando le variabili di istanza in un EJB, lo allo sviluppatore EJB è autorizzato a definirli per l'archiviazione intermedia. Forse ci sono valori intermedi, e vengono invocati metodi privati interni; anziché passare i parametri e/o creare un "oggetto di stato immediato" da passare a breve termine, uno sviluppatore (probabilmente pigro) può semplicemente utilizzare variabili di istanza.
La chiave qui, che è indirizzata dalle specifiche, è che, in nessun caso lo sviluppatore EJB supporre che tale campo manterrebbe informazioni significative attraverso invocazioni del bean.
Per quanto riguarda l'ultima citazione: La prego di aggiungere la versione e il paragrafo delle specifiche da lei citate. – Beryllium
@Beryllium Stavo tentando di sottolineare il punto, non citare nulla direttamente. Vedo che hai fornito una citazione pertinente - è grandioso. "Conversational" è esattamente il punto (e la dicitura specifica!) Che stavo tentando di fare. –
Una citazione dai chicchi EJB 3.1 spec
4,7 Stateless Session
bean di sessione senza sono i bean di sessione le cui istanze hanno alcuna conversazione Stato. Ciò significa che tutte le istanze di bean sono equivalenti quando non sono coinvolte nella manutenzione di un metodo richiamato dal client.
Il termine "stateless" indica che un'istanza non ha stato per un client specifico. Tuttavia, le istanze dell'istanza dell'istanza possono contenere lo stato tra le chiamate di metodo richiamate dal client.
Esempi di tale stato includono una connessione di database aperta e un riferimento a un oggetto bean enterprise.
L'enfasi è su senza stato di conversazione. Possono avere uno stato "altro".
Per esempio, ho usato per controllare se il carico è stato diffuso equamente su tutte le istanze in un nodo di cluster:
@Stateless(name = "DemoPingSb")
@Remote(DemoPingSbIfc.class)
public class DemoPingSb implements Serializable, DemoPingSbIfc {
private final AtomicInteger instancePingCount = new AtomicInteger(0);
private final static AtomicInteger classPingCount = new AtomicInteger(0);
public DemoPingSb() {
super();
}
public String ping(final String s) {
final int local = this.instancePingCount.incrementAndGet();
final int global = classPingCount.incrementAndGet();
System.out.println("INFO: local " + local + ", global " + global
+ ", s " + s);
return s.toUpperCase();
}
}
e se c'è abbastanza carico:
13: 13: 21.769 INFO [stdout] (http-localhost-127.0.0.1-8080-1) INFO: locale 22, globale 22, ciao
13: 13: 21,936 INFO [stdout] (http-localhost-127.0. 0.1-8080-1) INFO: locale 1, globale 23, ciao
Quindi ci sono alcuni casi particolari in cui questa funzione potrebbe essere utile.
Osservazioni
classPingCountAtomicInteger per instancePingCount potrebbe da sostituiti con volatile int, perché (4.10.13)Il contenitore deve garantire che solo un thread può essere in esecuzione una istanza di bean di sessione stateless o stateful in qualsiasi momento.
+1, ottimo riassunto. –
Definire "variabile globale"; Lo chiedo perché non è un termine Java standard e può significare cose diverse per persone diverse. –