Welchen Sinn hat eine globale Variable in einer Stateless Session Bean?

Question

Wir wissen, dass Stateless Session Beans keinen Zustand halten. Was ist der Sinn einer globalen Variable in einer Stateless Session Bean? Warum ist es nicht in der Spezifikation blockiert (um unnötige Verwirrung zu vermeiden)?

Wenn es praktische Vorteile gibt, globale Variable zu haben, erklären Sie bitte mit einem Stück Code-Fragment.

Answer 1

Offensichtlich muss jede Antwort angeben, dass ein Stateless EJB nicht den Status zwischen Aufrufen an Methoden auf dem EJB halten darf.

Anstatt einen Hard-Line-Ansatz zu wählen, indem man Instanzvariablen in einem EJB verbietet, darf der EJB-Entwickler sie für den Zwischenspeicher definieren ( ). Vielleicht gibt es Zwischenwerte, und interne private Methoden werden aufgerufen; anstatt Parameter zu übergeben und/oder ein "Immediate State Object" zu erstellen, das für die kurze Zeit übergeben wird, ein Entwickler (wohl faul) kann nur Instanzvariablen verwenden.

Der Schlüssel hier, die von der Spezifikation angesprochen wird, ist , die unter keinen Umständen sollte der EJB-Entwickler gehen davon aus, dass ein solcher Bereich aussagekräftige Informationen über Anrufungen des EJB halten würde.

Answer 2

Ein Zitat aus den EJB 3.1 spec

4,7 Stateless Session Beans

Stateless Session Beans Session sind Bohnen, deren Instanzen haben kein Konversations Zustand. Dies bedeutet, dass alle Bean-Instanzen gleichwertig sind, wenn sie nicht an der Bearbeitung einer vom Client aufgerufenen Methode beteiligt sind.

Der Begriff "zustandslos" bedeutet, dass eine Instanz für einen bestimmten Client keinen Status hat. Die Instanz Variablen der Instanz kann jedoch den Status zwischen clientaufgerufenen Methodenaufrufen enthalten.

Beispiele für einen solchen -Status sind eine offene Datenbankverbindung und ein Objektverweis auf ein Enterprise-Bean-Objekt.

Die Betonung liegt auf kein Gespräch Zustand. Sie können einen "anderen" Zustand haben.

@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(); 
    } 
} 

und wenn es genug Last:

---

Zum Beispiel habe ich es zu überprüfen, ob die Last verteilt wurde gleichmäßig über alle Instanzen in einem Cluster-Knoten verwendet, 13: 13: 21,769 INFO [stdout] (http-localhost-127.0.0.1-8080-1) INFO: lokale 22, globale 22, s hallo
13: 13: 21,936 INFO [stdout] (http-localhost-127.0. 0.1-8080-1) INFO: lokal 1, global 23, s hello

So gibt es einige spezielle Fälle, in denen diese Funktion nützlich sein könnte.

Bemerkungen

• Die Spezifikation spricht über Instanzvariablen; die Verwendung einer statischen Variablen ist dort nicht abgedeckt. So könnte der Code nicht korrekt in Bezug auf classPingCount
• Die Verwendung eines AtomicInteger für instancePingCount könnte durch mit volatile int ersetzt, weil (4.10.13)

Der Behälter muss sicherstellen, dass nur ein Thread kann die Ausführung werden eine Stateless oder Stateful Session Bean Instanz jederzeit.

• Eine Stateless Session Bean wird nie passiviert (4,2)