# JSF refresh vs. session scope



## Marsman (13. Mai 2008)

Hallo Ihr!

Ich habe mal wieder eine Frage bzgl. JSF und "best practice": Häufig sieht man für Managed Beans folgende Patterns. Ich frage mich dabei, welche Vor- oder Nachteile diese im Vergleich miteinander haben.

Bean im Request-Scope:


```
public class RequestBean {

  DataModel data;

  public RequestBean() {
    this.data = loadData();
  }

  public DataModel getData() {
    return this.data;
  }
}
```

Bean im Session-Scope:


```
public class SessionBean {

  DataModel data;

  public SessionBean() {
    reset();
  }

  public DataModel getData() {
    if (data == null) {
      this.data = loadData();
    }
    return this.data;
  }

  public void reset() {
    this.data = null;
  }
}
```

Ist das einfach nur eine Frage des persönlichen Geschmacks oder gibt es bestimmte Gründe, die eine oder andere Variante vorzuziehen?


Titus


----------



## maki (13. Mai 2008)

Dir ist der Unterschied zwischen den beiden klar?


----------



## Marsman (13. Mai 2008)

maki hat gesagt.:
			
		

> Dir ist der Unterschied zwischen den beiden klar?



Beim Request-Scope wird die Bean mit jedem Request neu instanziert. Also quasi jedes Mal, wenn der Browser die zugehörige Seite anzeigt (deshalb kann das Laden der Daten auch im Konstruktor liegen). Beim Session-Scope hingegen nur einmal zu Beginn der Session, also wenn ein User die Anwendung zum ersten Mal aufruft (deshalb muss das refreshen der Daten anderweitig bewerkstelligt werden).

Ich denke, es gibt je nach Lebensdauer einer Session Unterschiede bzgl. Speicherresourcen im Server. Anderseits aber auch evtl. Probleme mit der Auslastung bei zu vielen Resource-Beans. Ist das richtig und gibt es noch andere Vor- und Nachteile?

Titus


----------



## Marsman (15. Mai 2008)

maki hat gesagt.:
			
		

> Dir ist der Unterschied zwischen den beiden klar?



Und nun? Lag ich richtig oder falsch? Was meinen die anderen? :roll: 

Titus


----------



## maki (15. Mai 2008)

IMHO sind deine Gedanken nicht verkehrt, allerdings kann man nicht pauschal beantworten was besser ist, lazy init oder nicht, dazu müsste man mehr wissen.


----------



## Terminator (15. Mai 2008)

mal theorethisch!


RequestBean:
- Sieht ja so aus, als wenn das immer laden tut, also auch bei nem Postback mit ValidierungsFehler, wenn da load ne DB-Action bedeutet finde ich das ne Verschwendung von Resourcen.
- Ausserdem, falls DB-Aktion, würde der User bei nem Vali-Fehlern auf einmal nen anderen Datenstand vorgesetzt bekommen, da Daten neu von DB abgerufen werden (ausser es wäre selbe connection in gleicher transaction)



SessionBean
- der Construktor ist doch sinnlos oder seh ich da was net?
- Sinn von reset versteh ich irgendwie sowie so net


----------



## Guest (15. Mai 2008)

Terminator hat gesagt.:
			
		

> ResourceBean: Sieht ja so aus, als wenn das immer laden tut, also auch bei nem Postback mit ValidierungsFehler, wenn da load ne DB-Action bedeutet finde ich das ne Verschwendung von Resourcen.



Es sei denn, es handelt sich z.B. um eine Liste, die bei jeder Anzeige der Seite die aktuellen Daten enthalten soll?




> SessionBean:
> - der Construktor ist doch sinnlos oder seh ich da was net?
> - Sinn von reset versteh ich irgendwie sowie so net



Eigentlich schon. Ich hatte in meinem Beispiel allerdings eine Methode vergessen. Dann wirds evtl. klarer:


```
public String edit() {
  // Code zur Parameterübergabe an Edit-Bean.
  reset();
  return "toEditPage";
}
```

reset() soll in der Bean im Session-Scope eigentlich nur bewerkstelligen, dass beim nächsten Betreten der Seite, die Daten der Liste erneut geladen werden. So z.B. auch beim Übergang zu einer Seite zum Editieren eines Datensatzes.

Ich gebe zu, dass mein Code etwas aus dem Zusammenhang gerissen ist. Ich habe diese Variante im Sun-Forum (siehe hier) gesehen und fand sie recht nice.

Titus


----------



## KSG9|sebastian (27. Mai 2008)

Ok, jetzt wirds ganz sinnbefreit. Einen Bean im Session-Scope abzulegen aber trotzdem bei jedem Request ein Reset zu fahren?? Was soll dass denn für einen Sinn haben?

Wenn ne Änderung passiert wird die Änderung in die DB geschrieben und der Bean aktualisiert. Die Codesnippets machen imho nur Sinn wenn in die Datenbank auserhalb der Anwendung geschrieben wird UND die Daten die von außen kommen auch wirklich Zeitkritisch zur anzeige kommen müssen.


----------



## Guest (27. Mai 2008)

KSG9|sebastian hat gesagt.:
			
		

> Ok, jetzt wirds ganz sinnbefreit. Einen Bean im Session-Scope abzulegen aber trotzdem bei jedem Request ein Reset zu fahren??



Nein, nicht bei jedem Request. Nur dann, wenn über eine andere View Daten geändert wurden. :noe: 

Im Grunde handelt es sich bei der Application um eine klassische Datenverwaltung. In einer View (1) wird eine Liste der Datensätze angezeigt. Über eine weitere View (2) kann ein einzelner Datensatz hinzugefügt, geändert oder gelöscht werden. Bei der Rückkehr in die View mit der Liste, soll diese neu geladen werden. Und zwar möglichst nur dann, wenn die Änderung tatsächlich durchgeführt wurde.

Je Anzeige gibt es eine Bean. Die Frage ist nun, wie Bean 1 von der durchgeführten Änderung in Bean 2 erfährt, um die Liste neu zu laden?? Und zwar ohne dass Bean 2 auf Bean 1 zugreift. Denn das ganze soll wiederverwendbar sein. View 2  kann also evtl. auch über View 3, 4 oder 5 aufgerufen werden.

Das mit dem allgemeinem reset() habe ich aufgrund der Empörung hier auch wieder entfernt.  Aber wie kann ich das Problem nun lösen?

Titus


----------



## Marsman (27. Mai 2008)

....der Gast war ich. :lol: 

Titus


----------

