Intelligentes Nachladen von Collections ?

Status
Nicht offen für weitere Antworten.

damien

Aktives Mitglied
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:

Java:
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 ?
 
S

SlaterB

Gast
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

Aktives Mitglied
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.
 
S

SlaterB

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

mvitz

Top Contributor
...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?
 
S

SlaterB

Gast
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
 

mvitz

Top Contributor
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?
 
M

maki

Gast
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.
 
M

maki

Gast
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

Aktives Mitglied
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 ?
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen


Oben