JPA und die Qual der Wahl

[Deadalus]

Hallo,

ich hab da mal eine Verständnisfrage.

Folgendes Beispiel:
Entity "a" mit einer one-to-many Beziehung zu einem anderen Entity "b".

Beim Start der Anwendung lese ich alle "a" Objekte aus der Datenbank. Dann wird durch einen Benutzerevent alle "b" Objekte eines bestimmten "a" Objektes benötigt.

Wie gehe ich nun am besten vor?

1. Möglichkeit: SessionBean: Stateful, Persistent Context: Extended.
Enitiy im Persistent Context belassen.
Lazy Load funktioniert überall in der Anwendung. Also kann ich an beliebiger Stelle einfach List<B> bs = a.getB(); schreiben.

2. Möglichkeit: SessionBean: Stateful, Persistent Context: Extended.
Enititys so früh wie möglich detachen (em.clear()).
Also muss ich um die b's zu bekommen wieder auf meine SessionBean zugreifen, wo ich das a Objekt merge, dann per Lazy Load auf die b Objekte zugreife und diese dann zurückgebe.

3. Möglichkeit: SessionBean: Stateless, Persistent Context: Transaction, Fetch Type: Eager
Ich kann überall in der Anwendung auf die b Objekte zugreifen weil sie schon mitgeladen wurden.

4. Möglichkeit: SessionBean: Stateless, Persistent Context: Transaction, Fetch Type: Lazy
Neues JQL Query indem ich die b's die dem a Objekt zugeordnet sind aus der DB lese.

Welche der Möglichkeiten macht am meisten Sinn? (In der endgültigen Version wird es definitv viel a Objekte mit noch mehr b Objekten geben)
Am bequemsten finde ich die Lösung, das alle Entitys einfach im Persistenz Context verbleiben aber wieviel kostet das an Leistung?

 

[MrWhite]

Mit einem Kollegen haben ich neulich mal 50 000 und 100 000 statt 10 000 Entities geladen und das hatte keinen feststellbaren Effekt auf die Performance. Nichtmal der Speicherverbrauch ging großartig nach oben. Als Persistence-Unit nutzen wir JBoss Hibernate. Um welche Größenordnungen handelt es sich denn bei dir?

Evtl. kann man das schon alles im Persistence-Context belassen.

 

[Deadalus]

Hmm das mit dem Umfang ist schwer zu sagen. Das wird sehr stark davon abhängen wo die Software eingesetzt wird. Allerdings ist es wohl vorgesehen für größere Kunden Anpassungen zu schreiben. Vielleicht muss ich selbst mal Performance Tests machen. Ich werde jetzt allerdings erst mal Möglichkeit 1 testen und schauen wann und ob ich an die Grenzen stoße.

 

[JanHH]

Macht es nicht Sinn, die Entscheidung von der Anwendungssituation abhängig zu machen? Je nachdem, wie nahe zeitlich die Auswahl der A's und B's zusammenliegt, ist mal die eine, mal die andere Variante besser. Entities während einer ganzen Session im erweiterten Persistenzkontext zu belassen, ist sicherlich Quatsch. Aber wenn es zeitlich direkt aufeinanderfolgende Aktionen sind, ist das Lazy Loading sicherlich nicht verkehrt.

Besteht beim erweiterten Persistenzkontext bei Beans im Session-Scope nicht allerdings die Gefahr, dass die Datenbank-Connections irgendwann aufgebraucht sind?

Optimal wäre da wahrscheinlich seam mit dem Conversation Scope, Lazy Loading und dem seam-managed persistence context. Da wird dann nur das geladen, was gebraucht wird, wenn es gebraucht wird, und der Peristenzkontext besteht auch nicht länger als notwendig.

 

[maki]

Macht es nicht Sinn, die Entscheidung von der Anwendungssituation abhängig zu machen?

Full ACK :toll:

Gutes Design bzw. Architektur kann man nicht im Vakuum erstellen, der Kontext muss immer berücksichtigt werden.
OPb Stateful oder Stateless ist weniger eine Frage der Persistenz als des Anwendungsfalles, speziell die Transaktionsgrenzen spielen hier eine wichtige Rolle.
Lazy Loading ist eigentlich immer gut, und wenn nicht, helfen Fetch Joins.