Intelligentes Nachladen von Collections ?

[damien]

Hallo,

ich hab folgendes Problem.

Klasse Autohaus mit einem Attribut List<Gebrauchtwagen> gebrauchtwagen;

Ich möchte die Gebrauchtwagen nicht gleich mitladen, sondern eben bei Bedarf, d.h. ich habe eine View und klicke auf das Autohaus, surfe da rum und möchte irgendwann die Gebrauchtwagen anschauen. Dazu habe ich eine Methode gebrauchtwagenNachladen(). Das Problem ist ja,
dass die App, dann jedes mal wenn ich auf den Link Gebrauchtwagen klicke die Actionmethode zum Nachladen aufruft und diese ja immer auf die DB geht oder nicht ?

Wenn ich sowas einbaue wie:

public String gebrauchtwagenNachladen() {

	if(autohaus.getGebrauchtwagen() == null && autohaus.getGebrauchtwagen().isEmpty()) {
	//Nachladen
	try {
			autohaus = autohausverwaltung.findAutohausFetchGebrauchtwagen(autohaus);
	}
	catch(blabla e)

	else{
		//Nicht nachladen
		return null;
	}	

return null;
}

Dann erfolgt ja immer ein DB-Zugriff bei erneuten Anklicken des Links oder nicht ?

 

[SlaterB]

beim Anklicken bzw. generell User-Aktionen besteht diese Problem eher nicht, zumindest im Web-Bereich ohne Spielereien wie JavaScript usw.,
denn du meinst wahrscheinlich einen neuen Request an den entfernten Web-Server,
das ist eh mit der kompletten neuen Verarbeitung verbunden, da stört der neue DB-Zugriff nicht,

insbesondere hätte es dir gar nichts gebracht, einen bestimmten Wagen oder alle schon vorher zu laden,
denn diese Daten von vor 10 Sekunden sind dann doch nirgendwo mehr vorhanden oder werden die irgendwo länger gespeichert?


-----

interessanter ist die Frage innerhalb eines Request, wenn die DB-Schicht nicht weiß, was die aktuelle View darstellen will (ohne User-Interaktion),
erst die Aktionen beim Rendern der View greifen auf Daten zu, die dann, falls nicht vorhanden, nachgeladen werden müssen

Open Session in View ist dazu ein Stichwort
erst die View greift auf die Daten zu, dann wird nachgeladen

 

[damien]

Erst mal vielen Dank für die Antwort.

Ich habe ja eine ManagedBean(Scope = Session) mit einem Attribut Autohaus, das ist vorhanden mit all seinen wichtigen Daten. Beim Klick auf Gebrauchtwagen wird eben die Methode von oben ausgeführt, mit einem Fetch Join. Das Problem ist, dass wenn ich auf z.B. Kontakt gehe und danach wieder auf Gebrauchtwagen, sagen wir innerhalb von 15 sec, dass dann wieder ein DB Zugriff stattfindet und wieder und wieder. Das möchte ich eben vermeiden, dass wenn man innerhalb kurzer Zeit auf eine andere View navigiert und dann wieder zu den Gebrauchtwagen, dass eben ein DB Zugriff stattfindet, wo die Gebrauchtwagen doch schon vor 15 sec geladen wurden.

 

[SlaterB]

ich kann dazu nix weiter sagen, außer dass es mir befremdlich erscheint, Daten mehr für einen Request vorzuhalten

 

[mvitz]

...Das Problem ist, dass wenn ich auf z.B. Kontakt gehe und danach wieder auf Gebrauchtwagen, sagen wir innerhalb von 15 sec, dass dann wieder ein DB Zugriff stattfindet und wieder und wieder. Das möchte ich eben vermeiden, dass wenn man innerhalb kurzer Zeit auf eine andere View navigiert und dann wieder zu den Gebrauchtwagen, dass eben ein DB Zugriff stattfindet, wo die Gebrauchtwagen doch schon vor 15 sec geladen wurden.

Würde man das nicht Allgemein unter Caching verstehen und müsste Hibernate/Eclipse TopLink das nicht idr selber sogar automatisch machen?

 

[damien]

ich kann dazu nix weiter sagen, außer dass es mir befremdlich erscheint, Daten mehr für einen Request vorzuhalten

Verstehe nicht ganz was du meinst ?

 

[SlaterB]

wenn ein User-Request kommt hat man herkömmlicherweise, so wie ich es kenne, keine Daten vorliegen,
sondern lädt alles was aktuell benötigt wird, neu aus der DB oder evtl. aus einem Cache,

vom vorherigen Request speichert man nichts in längerlebigen Objekten, denn der User könnte 2 Min. warten mit dem nächsten Klick oder seinen Browser ausschalten

 

[maki]

Würde man das nicht Allgemein unter Caching verstehen und müsste Hibernate/Eclipse TopLink das nicht idr selber sogar automatisch machen?

Das nennt sich "Lazy Load" und ist eine Standard Funktion von JDO, JPA/Hibernate/EclipseLink etc. pp.

 

[mvitz]

Das nennt sich "Lazy Load" und ist eine Standard Funktion von JDO, JPA/Hibernate/EclipseLink etc. pp.

Das erschlägt aber nicht ganz das Szenario des TOs. Lazy Load wird ja idr. für Collections eingesetzt, damit diese nicht vollständig geladen werden müssen, wenn man sie evtl. gar nicht benutzt.
ABER
Der TO hat ja ein Szenario aufgezigt, wo ein Benutzer Seite A betritt --> DB Query, anschließend wechselt er auf Seite B und direkt danach wieder auf Seite A (wodurch normalerweise wieder dasselbe DB Query ausgeführt wird). Dieses Szenario ließe sich mit einer guten Caching-Strategie optimieren, sodass eben beim zweiten Laden von Seite A direkt aus dem Cache geantwortet wird. Und soweit ich das richtig in Erinnerung habe, macht Eclipse Link/Hibernate doch eine gewisse Art von Caching automatisch, oder?

 

[maki]

Das erschlägt aber nicht ganz das Szenario des TOs. Lazy Load wird ja idr. für Collections eingesetzt, damit diese nicht vollständig geladen werden müssen, wenn man sie evtl. gar nicht benutzt.
ABER
Der TO hat ja ein Szenario aufgezigt, wo ein Benutzer Seite A betritt --> DB Query, anschließend wechselt er auf Seite B und direkt danach wieder auf Seite A (wodurch normalerweise wieder dasselbe DB Query ausgeführt wird). Dieses Szenario ließe sich mit einer guten Caching-Strategie optimieren, sodass eben beim zweiten Laden von Seite A direkt aus dem Cache geantwortet wird. Und soweit ich das richtig in Erinnerung habe, macht Eclipse Link/Hibernate doch eine gewisse Art von Caching automatisch, oder?

Ach so war das gemeint.. dann ist Caching natürlich richtig.
Klar Cached Hibernate bzw. die anderen JPA Implementierungen.

 

[damien]

Okay, wie kann ich überprüfen ob die Daten aus dem Cache kommen, oder aber aus der DB ?

 

[maki]

Okay, wie kann ich überprüfen ob die Daten aus dem Cache kommen, oder aber aus der DB ?

zB. die Logs einschalten & ansehen

Ist aber imho der falsche Weg wenn ich das so sehe..
Grundregel: Optimiert wird erst wenn es zu langsam ist, und dann benutzt man einen Profiler.

 

[damien]

Sorry für die blöde Frage, aber wie sehe ich das in den Logs ?

 

[maki]

Na ob eine SQL Abfrage an die DB gemacht worden ist...

 

[damien]

Ich logge mit DEBUG [org.hibernate.SQL] mit und da stehen halt immer wieder die SQL Statements, wenn ich mir die Gebrauchtwagen anzeigen lassen will. Das deutet dann auf einen DB-Zugriff hin, richtig ?

 

[FArt]

Tipp:
https://www.hibernate.org/15.html

Man bekommt über Logging auch mit, ob ein Statement ausgeführt wird, oder ob Objekte aus dem Cache genommen werden.

 

[damien]

Tipp:
https://www.hibernate.org/15.html

Man bekommt über Logging auch mit, ob ein Statement ausgeführt wird, oder ob Objekte aus dem Cache genommen werden.

Hm und wie ? Das kann ich dem Dokument leider nicht entnehmen.