JPA (EntityManager für jeden Nutzer?)

Status
Nicht offen für weitere Antworten.

SegFault

Bekanntes Mitglied
So eine Frage hätte ich noch. Ist es Sinnvoll für jeden, im gesamt DB-System angemeldeten Nutzer, einen eigenen EntityManager zu erzeugen?
Da ich meine Anwendung nun doch als ApplicationServer Anwendung stricke, kommen die Zugriffe ja übers Netz. Es wird also nicht gewährleistet wann, wer, was macht. Gerade bei Transaktionen sehe ich da ein Problem. Wenn jeder Nutzer seine eigenen EntityManager hat, ist das doch prinzipiell so wei eine eigene Datenbankanbindung? Oder sehe ich das falsch.
 
Nein, das siehst du ein wenig falsch. Der App-Server hat einen Connection-Pool, aus dem er eine freie rausnimmt wenn der User mit der DB kommuniziert. Du wirst also nicht mit Connection-Requests zur DB überflutet und das ganze wird relativ effizient verwaltet.
 
MrWhite hat recht, ausserdem sollte man nicht in "Benutzern" sondern in "Threads" denken.
 
D.H. es reicht ein EntityManager und ich kann mit getTransaction().begin(); und getTransaction().commit() bzw. rollback()
alles handeln? Oder muss ich das ganze nun noch mit synchronized absichern? Weil ich ja noch nicht genau weiss wann welcher nutzer etwas anfordert. Nicht das sich jetzt Transaktionen gegenseitig beeinflussen. (Nutzer 1 will ein insert machen und startet eine Transaktion, Nutzer 2 macht ein update und startet auch eine Transaktion, Nutzer 2 commited seine Transaktion eher). Was ist mir der Transaktion von Nutzer1 wenn beides aus dem gleichen entityManager gestartet wird und ich immer mit em.getTransaction().begin(), em.getTransaction().commit() arbeite. (Ggf ist diese Vorgehensweise falsch).
 
Wie gesagt, vergiss die Benutzer, denke in Threads, ein Benutzer kann mehrere Threads gleichzeitig bzw. schnell hineinander abfeuern, Transaktionen sind normalerweise an den Thread & die Connection gebunden.

Ich würde die Transaktionen nicht manuell & hardcodiert in code Starten & Beenden, nicht praktisch & nicht schön & mit der Zeit sehr kompliziert.
Sowohl JEE als auch Spring bieten die Möglichkeit Transaktionen Deklarativ zu steuern, sollte unbedingt(!!!) genutzt werden.
 
AFAIK nutze ich JEE zumindest nutze ich die javaee-api für die javax.Persistence geschichte. Hab aber nichts konkretes zum Managen der Transactions gefunden.
 
Da gibt es viele Möglichkeiten um Transaktionen deklarativ zu steuern.

EJB 3.0 bringt das z.B. mit. Dann wären da noch SEAM und Spring zu erwähnen, die so etwas ebenfalls besitzen.

Für EJB 3.0:
TransactionAttribute (Java EE 5)
TransactionAttributeType (Java EE 5)
http://www.javapassion.com/j2ee/jpatransaction.pdf

Mit SEAM kann man sich auch direkt die Transaktion injizieren lassen und damit klassisch imperativ Schindluder treiben, wenn man will.

Nicht zuletzt hat doch der EntityManager auch noch eine getTransaction()-Methode, aber ob man mit der was anfangen kann, hängt von der Konfiguration des Persistence-Kontext ab.
 
Manchmal ists doch recht sinnvoll eine Nacht über ein Problem zu schlafen, gestern hab ich die Links noch nicht verstanden. Heute sieht das schon anders aus. Ich werds mal mit den Transaction Attribute versuchen. Das wirkt recht brauchbar für meine Zwecke. So wirklich aufwendig ists das ganze bei mir auch noch nicht. Ich markier das ganze vorerst als Erledigt. Könnte aber sein das ichs nochmal öffne. Danke für die gute Info. Hat mir erstmal ziemlich geholfen.
 
Ok, ich muss nochmal berichtigen. Ich benutze keine ejb Beans und auch kein Spring framework. Ich verwende Hibernate bisher so das ich getEntityManagerFactory("blah"); aufrufe und den EntityManager darüber mit getEntityManager hole. Sind die bisher gemachten Angaben noch richtig? Also die Bindung der Transaction an den Thread und die Connection? Im grunde ist das ja meine eigene Anwendung, ich verteile Sie nur über RMI.
 
Status
Nicht offen für weitere Antworten.

Zurück
Oben