static in servlets

[herr reporter]

Kann ich in einem Servlet eine Variable (z.B. das Ergebnis einer Datenbankabfrage) statisch deklarieren, damit sie dann auch für spätere Requests zur Verfügung steht?
Ich stelle mir das ungefähr so vor:

public class xmlrpc extends HttpServlet {

public static String result = null;

  public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
    doRequest(req, res);
  }

  public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
    doRequest(req, res);
  }
	
  public void doRequest(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
    if  (result == null) result = getResult();
    System.out.println(result);
  }

  private String getResult() {
    String result = new String();
    // Result aus einer Datenbank lesen
    ...
    return result;
  }
}

Das Servlet schaut also erst, ob das Result schon da ist, wenn nicht, wird es neu geladen. Ansonsten kann es sich den Datenbankaufruf sparen.
Wie lange ist result gültig? Bis der Request abgearbeitet ist oder bis der Server neu gestartet wird?

 

[KSG9|sebastian]

statisch deklarieren damit es im request verfügbar ist ? hae ?

request.setAttribute("meinVar", meinVar);

??

 

[herr reporter]

die Variable soll beim nächsten aufruf des servlets wieder verfügbar sein

 

[Bleiglanz]

lebt ewig...ist aber schlecht (mutithreaded?)

 

[Karl]

Hallo,

wenn Du nicht gerade das SingleThread-Modell verwendest (sowieso verpönt), gibt es
doch sowieso nur eine Instanz des Servlets - wozu also statisch? Alle Aufrufe
gehen darüber und sehen auch dieselben Instanzvariablen; den Zugriff darauf muss
man synchronisieren.

Normalerweise vermeidet man aber Instanzvariablen, Du solltest über die Verwendung
von Sessions nachdenken, die haben einen Session-Context.

Noch am Rande: Ein DB-Resultset solltest Du keinesfalls offen lassen, besser
zum Cachen irgendeine Struktur befüllen.

Gruß,
Karl

 

[Bleiglanz]

@Karl

nein, es kann mehrere geben (wenn der Webcontainer das so will) damit mehrere Abfragen gleichzeitig bearbeitet werden können

ich würds auch als member Variable machen (und gleich in der init-Methode befüllen), oder gleich den String als Attribut in den ServletContext legen und beim Hochfahren der Anwendung über einen Listener initialisieren

 

[Karl]

@Bleiglanz,

meinem Verständnis nach gilt das nur für das SingleThreadModel,
aus der Servlet-Spezifikation:

SRV.2.2 Number of Instances
The servlet declaration which is part of the deployment descriptor of theWeb application
containing the servlet, as described in Chapter SRV.13, “Deployment
Descriptor”, controls how the servlet container provides instances of the servlet.
For a servlet not hosted in a distributed environment (the default), the servlet
container must use only one instance per servlet declaration. However, for a servlet
implementing the SingleThreadModel interface, the servlet container may
instantiate multiple instances to handle a heavy request load and serialize requests
to a particular instance.

Daran muss sich der Container halten.

Gruß,
Karl

 

[Bleiglanz]

@Karl

Sorry, hab mal wieder Mist erzählt

irgendwie war mir das nicht mehr klar; ich hatte immer im Kopf, dass man die Poolgrösse einstellen kann (tatsächlich heisst das Tag bei Sun z.B. "singleThreadedServletPoolSize" )

Eigentlich auch logisch: wenns mutithreaded ist, braucht der Container nicht mehr als eine Instanz.