Hibernate: Löschen vor Speichern

[The_S]

Hi-Ho,

ich habe eine Tabelle mit einer UniqueConstraint. Aus dieser Tabelle soll in einem Atemzub (in einer Transaktion) Zeilen gelöscht und wieder hinzugefügt werden. Wenn ich jetzt blöderweise über entityManager.remove eine Zeile lösche, und dann später wieder eine Zeile mit der selben UniqueConstraints hinzufüge, fliegt das Ganze auf die Schnauze, weil Hibernate scheibar zuerst alle inserts (entityManager.persist) ausführt und dann erst deletet. Es kann aber sein, dass ein UniqueConstraint zuerst gelöscht und dann wieder hinzugefügt wird (nein, ich hab mir dieses Szenario nicht ausgedacht, ich darf es nur ausbaden). Wie bringe ich Hibernate bzw. Standard-JPA dazu, dass zuerst gelöscht und dann hinzugefügt wird?

Danke!

 

[SlaterB]

session.flush();

 

[The_S]

ungünstig. Wir haben momentan eher eine ... naja ... sagen wir mal: Notlösung am laufen => Kein Webserver, WebService wird über Java-6 WebService ohne Server realisiert, Transaktionsmanagment wird in der WebService-Methose manuell "angeregt". Diese WebService Methode delegiert die Arbeit an untergeordnete Methoden, die sich um das eigentliche Löschen und Schreiben kümmern. Die WebService Methode ist nur für das Transaktionsmanagement und Konvertierung des Rückgabewerts der untergordneten Methode zuständig. Somit kann ich kein session.flush() Aufrufen, bevor nicht die komplette Arbeit erledigt wurde.

 

[SlaterB]

siehe auch

Google
[#HHH-2801] wrong insert/delete order when updating record-set - Hibernate JIRA
https://forum.hibernate.org/viewtopic.php?p=2382504
leider anscheinend ohne Lösung

(wenn du es schon kanntest, dann hättest du es posten können)

 

[The_S]

Nein, kannte ich nicht. Danke, werde ich mir mal durchlesen. Es kann aber nicht sein, dass sich einfach nicht die Reihenfolge der Transaction gemerkt wird. Also so langsam aber sicher sehe ich in Hibernate (ein bisschen), aber vor allem in JPA mehr Zusatzarbeit als Erleichterung.

 

[SlaterB]

wenn du die Wahl hättest, es anders zu implementieren,
dann müsste doch irgendwie auch die Möglichkeit bestehen, ein flush auszulösen,

der Aufrufer muss ja nicht direkt selber das Session-Objekt in die Finger bekommen,
sondern nur eine bestimmte Methode 'nunLoeschIchNichtMehr()' aufrufen, die intern dann zum flush() führt

 

[The_S]

Das hätte eine ziemlich große Umstellung unserer Struktur zur Folge. Ich werde es jetzt wohl auf zwei Methoden ausweiten und zwei Transaktionen öffnen/schließen. Ist zwar besch*****, aber was will man machen.

Ich werde wohl in allen zukünftigen Projekten darauf beharren, unbedingnt nicht mit Hibernate/JPA zu arbeiten, bis diese Projekte endlich mal ihre Kinderschuhe verlassen haben. :noe:

 

[byte]

Irgendwie verstehe ich das Problem nicht so ganz. Warum kannst Du kein session.flush() machen?

 

[The_S]

Zum Einen will ichs nicht machen, weil es einfach nur Unfug ist, wenn meine Statements nicht in der Reihenfolge abgearbeitet werden, in der ich sie aufrufe.

Ansonsten sieht meine Methode bspw. so aus:

@WebMethod
public String deleteAndInsertSomething(String something) {

  // Fürs Exceptionhandling bin ich grad zu faul
  beginTransaction();
  facade.deleteAndInsertSomething(something);
  commitTransaction();
}

Beide Aktionen, löschen und einfügen, werden aber in facade.deleteAndInsertSomething ausgeführt. Dort möchte ich (und auch eigentlich sonst niemand hier) aber kein Transaktionsmanagement haben.

Trotzdem danke für deine/eure Antworten.

 

[maki]

Was ich nicht verstehe wieso kein Update verwendet wird, sondern mit "Gewalt" erst die Datensätze gelöscht werden sollen die sofort wieder hinzugefügt werden sollen.

 

[The_S]

Es werden mehrere Datensätze bearbeiten. Nicht alle, die hinzugefügt werden, müssen auch schon vorhanden sein. Das bedeutet Aufwand, da jeder Datensatz einzeln geprüft werden müsste. Zum Anderen schlägt das Einfügen aufgrund eines UniqueKeys fehl. Die Tabelle verfügt aber noch über weitere, nicht eindeutige Felder + einer ID. Es ist für die Anwendung an dieser Stelle zwingend erforderlich, dass eine neue ID generiert wird.

 

[byte]

Zum Einen will ichs nicht machen, weil es einfach nur Unfug ist, wenn meine Statements nicht in der Reihenfolge abgearbeitet werden, in der ich sie aufrufe.

Ansonsten sieht meine Methode bspw. so aus:

@WebMethod
public String deleteAndInsertSomething(String something) {

  // Fürs Exceptionhandling bin ich grad zu faul
  beginTransaction();
  facade.deleteAndInsertSomething(something);
  commitTransaction();
}

Beide Aktionen, löschen und einfügen, werden aber in facade.deleteAndInsertSomething ausgeführt. Dort möchte ich (und auch eigentlich sonst niemand hier) aber kein Transaktionsmanagement haben.

Trotzdem danke für deine/eure Antworten.

Moment mal. Ein Session#flush() hat nichts mit Transaktionsmanagement zu tun. Wenn Du in deleteAndInsertSomething() nach dem Delete ein flush() machst, wird doch lediglich das SQL rausgeschickt. Die Transaktion wird nicht committed. Du kannst locker mehrmals in der gleichen Transaktion flushen. Ich sehe also das problem hier nicht. Denn genau für sowas ist flush() doch da.

 

[maki]

Es werden mehrere Datensätze bearbeiten. Nicht alle, die hinzugefügt werden, müssen auch schon vorhanden sein. Das bedeutet Aufwand, da jeder Datensatz einzeln geprüft werden müsste. Zum Anderen schlägt das Einfügen aufgrund eines UniqueKeys fehl. Die Tabelle verfügt aber noch über weitere, nicht eindeutige Felder + einer ID. Es ist für die Anwendung an dieser Stelle zwingend erforderlich, dass eine neue ID generiert wird.

Ok, verständlich.

Die Reihenfolge wird von hibernate selbst "optimiert", um sich unnötige SQl Abfragen (und den damit verbundenen Overhead) zu ersparen, d.h. Hibernate wird meckern wenn es merkt dass ein Datensatz zuerst gelöscht werden soll nur um danach wieder eingefügt zu werden.

Könnte da falsch liegen, aber ein flush sollte keine Transaktion commiten.

 

[The_S]

Moment mal. Ein Session#flush() hat nichts mit Transaktionsmanagement zu tun. Wenn Du in deleteAndInsertSomething() nach dem Delete ein flush() machst, wird doch lediglich das SQL rausgeschickt. Die Transaktion wird nicht committed. Du kannst locker mehrmals in der gleichen Transaktion flushen. Ich sehe also das problem hier nicht. Denn genau für sowas ist flush() doch da.

Sorry, im Eifer des Gefechts habe ich wohl nicht genau hingesehen/nachgedacht. Eigentlich widerstrebt es mir nur, ein flush() auszuführen. Warum können nicht einfach die Statements in der Reihenfolge abgesetzt werden, in der ich sie aufrufe? Naja gut, danke nochmals, ich werde es mal mit nem flush (widerwillig ) versuchen.

 

[maki]

Warum können nicht einfach die Statements in der Reihenfolge abgesetzt werden, in der ich sie aufrufe?

Habe ich dir doch versucht zu erklären

 

[byte]

Sorry, im Eifer des Gefechts habe ich wohl nicht genau hingesehen/nachgedacht. Eigentlich widerstrebt es mir nur, ein flush() auszuführen. Warum können nicht einfach die Statements in der Reihenfolge abgesetzt werden, in der ich sie aufrufe? Naja gut, danke nochmals, ich werde es mal mit nem flush (widerwillig ) versuchen.

Es wird sicherlich Gründe geben, warum die Reihenfolge der SQL-Statements so gewählt wurde wie sie sind (siehe maki). Für genau solche Fälle, wo einem das nicht passt, gibt es Session#flush().
Ich verstehe Deine Bedenken nicht gegen den Aufruf von flush(). Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!

 

[The_S]

Habe ich dir doch versucht zu erklären

ups, hab ich übersehen. Ja, das klingt plausibel. Trotzdem sollte es nichts optimieren, wenns ohne Optimierung geht, aber mit nicht. Das wäre dann irgendwie am Ziel "vorbeioptimiert" .

 

[SlaterB]

> Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!

wenn es keinen gäbe, wieso ist das dann nicht automatisch zumindest bei Session.delete() eingebaut?
wenn man geänderte Objekte in der Session hat, die später noch weiter geändert werden,
werden unnötig Zwischenzustände in die DB geschrieben

-----

einen Optimierungssinn zu delete vor insert ist mir auch noch nicht bekannt,
für mich ein Bug

 

[The_S]

Es wird sicherlich Gründe geben, warum die Reihenfolge der SQL-Statements so gewählt wurde wie sie sind (siehe maki). Für genau solche Fälle, wo einem das nicht passt, gibt es Session#flush().
Ich verstehe Deine Bedenken nicht gegen den Aufruf von flush(). Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!

Sorry, hatte ich schon wieder übersehen (ihr schreibt aber auch verdammt schnell ). Aber ich schließe mich da einfach mal der Aussage von Slater an .

 

[byte]

> Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!

wenn es keinen gäbe, wieso ist das dann nicht automatisch zumindest bei Session.delete() eingebaut?

Das wäre doch sehr sinnfrei.

Es ist natürlich schneller, alle Deletes / Inserts am Stück zu machen, daher sollte man natürlich nicht wahllos alles sofort flushen. Aber in diesem speziellen Fall ist halt flush() die Lösung. Daher wollte ich von Hobbit wissen, was er in diesem speziellen Fall gegen flush() hat!

 

[The_S]

Also es funktioniert auch mit flush(). Soweit so gut. Danke für den Hinweis. Trotzdem habe ich was dagegen, wenn mich eine automatisierte Optimiererei, die ich nicht eingeschaltet/gewollt/... habe, in meiner Arbeit zurückwirft bzw. wertvolle Zeit kostet. Wenn schon automatisch optimiert wird, dann muss auch sichergestestellt werden, dass es auch funktioniert, wenn es ohne Optimierung geht. just my 2 cents

 

[maki]

Die automatische Optimierung funktioniert, ohne sie wäre Hibernate bzw. die meisten ORM nicht einsetzbar weil zu langsam.
Du hast einen atypischen Fall und deswegen musst du flush einsetzen, ist oft der Fall bei atypischen Fällen.

 

[byte]

Hibernate ist ein extrem mächtiges Framework, das aber auch extrem viel Knowhow erfordert, um es richtig einsetzen zu können.

Wenn Du weisst, wie Hibernate funktioniert, dann kannst Du extrem effizient Persistenz implementieren. Aber bis man wirklich von sich behaupten kann, ein Hibernate Experte zu sein, vergehen diverse Monate.

Hibernate ist keine einfache Lib, mit der jeder Nub Persistenz realisieren kann.

Wenn Du der Meinung bist, Hibernate macht Dir mehr Probleme als es löst, dann stehts Dir frei, das alles selbst per JDBC zu implementieren. Ich bezweifel aber mal stark, dass Du damit die gleiche Effizienz erreichen wirst.

 

[The_S]

Die automatische Optimierung funktioniert, ohne sie wäre Hibernate bzw. die meisten ORM nicht einsetzbar weil zu langsam.

Och ... naja ... wenn ich mir da teilweise die logs ansehe ... *grusel*. Ansich ist es schon ne gute Sache, aber für meine Bedürfnisse nach wie vor zu unausgereift.

 

[SlaterB]

> Du hast einen atypischen Fall und deswegen musst du flush einsetzen, ist oft der Fall bei atypischen Fällen.

diese Interpretation kann ich nicht nachvollziehen,

klar ist der Fall atypisch,
aber genauso atypisch ist es, mit Quicksort eine sortierte Liste zu sortieren, was dann zur schlechtestmöglichen Laufzeit führt,
dass aber die Sortierung dann mit Fehler scheitert, wäre doch wohl undenkbar

genauso muss auch Hibernate sein, vielleicht langsam, aber auf jeden Fall korrekt, gerade wenn der User so schlau ist,
in korrekter Reihenfolge einzufügen und zu entfernen

> Wenn Du der Meinung bist, Hibernate macht Dir mehr Probleme als es löst, dann stehts Dir frei, das alles selbst per JDBC zu implementieren.
> Ich bezweifel aber mal stark, dass Du damit die gleiche Effizienz erreichen wirst.

das ist ja etwas billig, man darf doch wohl im neutralen Ton Kritik anbringen,
die dann wenn überhaupt, mit richtigen Argumenten begegnet werden muss

 

[byte]

Och ... naja ... wenn ich mir da teilweise die logs ansehe ... *grusel*. Ansich ist es schon ne gute Sache, aber für meine Bedürfnisse nach wie vor zu unausgereift.

Hast du mal ein Beispiel, wovon Du sprichst?
Wie jedes Framework ist auch Hibernate nicht perfekt. Aber angesichts der komplexen Thematik (Datenbanken), macht Hibernate schon einen extrem guten Job. Zumindest gibts in meinen Augen keine Alternative, oder kennt ihr eine?

 

[maki]

Kann byto da nur zustimmen, HIbernate verwenden will gelernt sein, denn wenn Hibernate etwas nicht ist, dann "non-invasive" (auch wenn es immer so angepriesen wird) oder gar intuitiv, aber dafür ist das ganze Thema ORM viel zu komplex.

Die Lernkurve ist steil und auch lang, man wird immer wieder überrascht.

Gehen wir nochmal kurz auf das atypische an deinem Anwendungsfall ein:

Es werden mehrere Datensätze bearbeiten. Nicht alle, die hinzugefügt werden, müssen auch schon vorhanden sein. Das bedeutet Aufwand, da jeder Datensatz einzeln geprüft werden müsste.

Hibernate macht genau eine Abfrage (in Java, nicht der DB) um zu Wissen ob ein Objekt neu ist oder bereits in der DB abgelegt war, nämlich die ID prüfen.
Wenn man das weiss strukturiert man seine Logik so, um daraus einen Vorteil zu gewinnen.

 

[The_S]

Wenn Du weisst, wie Hibernate funktioniert, dann kannst Du extrem effizient Persistenz implementieren. Aber bis man wirklich von sich behaupten kann, ein Hibernate Experte zu sein, vergehen diverse Monate.

Das bin ich auch garantiert nicht und möchte ich zum jetztigen Zeitpunkt auch gar nicht sein .

Wenn Du der Meinung bist, Hibernate macht Dir mehr Probleme als es löst, dann stehts Dir frei, das alles selbst per JDBC zu implementieren. Ich bezweifel aber mal stark, dass Du damit die gleiche Effizienz erreichen wirst.

Wie bereits hier erwähnt (aber evtl. mit etwas zu wenig Nachdruck): Hibernate ist größtenteils akzeptabel, auch wenn ich nicht verstehe, warum manche Dinge nicht gleich richtig implementiert wurden bzw. es so unnötig komplex und aufgebläht ist. Hauptproblem habe ich mit der JPA-Spezifikation, die ja wahrlich doch sehr beschränkt ist. Wir programmieren zwar momentan mit Hibernate, das ist aber nur eine temporäre Lösung bis der SAP NetWeaver steht - und der hält sich so genau an den schlechten JPA-Standard, mit dem man bestenfalls irgendwelche 08/15 Hobbyprojekte realisieren möchte. Ich werf nur mal Dinge in den Raum wie: Keine Berechnungen im NamedQuery, bei Aufruf eines Konstruktors darf kein ORDER BY dabei sein, Left Outer Joins über Tabellen, die nicht in der Entity referenziert sind, Foreign Keys die Gleichzeitig auch als Primary Key fungieren sollen, ... Na klar umgeht Hibernate viele Probleme, aber eben nicht alle.

Zudem kommt es bei diesem Projekt sehr auf die Performance an - bevor ich stundenlang an einem NamedQuery tüftle und dann doch noch die Hälfte außerhalb des Querys in einer Java-Klasse erledigen muss, bin ich an dieser Stelle wirklich mit JDBC effizienter. Außerdem wird sich die Datenbank, die der Anwendung zugrunde liegt, ohnehin nie ändern. Aber da hat wohl eher unser Architekt gepennt ... :autsch:

 

[byte]

klar ist der Fall atypisch,
aber genauso atypisch ist es, mit Quicksort eine sortierte Liste zu sortieren, was dann zur schlechtestmöglichen Laufzeit führt,
dass aber die Sortierung dann mit Fehler scheitert, wäre doch wohl undenkbar

genauso muss auch Hibernate sein, vielleicht langsam, aber auf jeden Fall korrekt, gerade wenn der User so schlau ist,
in korrekter Reihenfolge einzufügen und zu entfernen

Bei DB Statements spielt Performance eine sehr große Rolle. Hibernate optimiert hinsichtlich der Performance, was in diesem Fall Probleme bereitet. Hibernate bietet aber auch eine Lösung mittels flush(). Insofern ist das Problem neutralisiert.
Du schreibst, Hibernate muss in jedem Fall fehlerfrei funktionieren. Wie soll das bitte gehen? Hibernate kann nicht jede Exception der DB im Vorraus berechnen und entsprechend darauf reagieren bzw. sie verhindern.
Zumal auch nicht jede DB gleich ist. Bei Oracle gibts z.b. die Möglichkeit, Constraints erst beim Commit der Transaktion zu checken. Da würde o.g. Problem gar nicht auftreten.

 

[The_S]

Hibernate macht genau eine Abfrage (in Java, nicht der DB) um zu Wissen ob ein Objekt neu ist oder bereits in der DB abgelegt war, nämlich die ID prüfen.
Wenn man das weiss strukturiert man seine Logik so, um daraus einen Vorteil zu gewinnen.

Womit wir beim nächsten Problem des Projekts wären. Bei einer sehr alten Anwendung, die über 10 Jahre lang gewachsen ist, wird der Datenbanktreiber nicht mehr offiziell unterstützt. Es ist nur noch eine Frage der Zeit, bis uns das Ding um die Ohren fliegt. Ziel war/ist es jetzt "auf die schnelle" ein anderes Backend für diese Anwendung aufzubauen. Deshalb müssen wir uns an dieser Stelle an die Logik der alten Applikation halten. Bei einer späteren Neuentwicklung der gesamten Anwendung sieht die Welt schon wieder ganz anders aus. Da gebe ich dir dann natürlich recht. Aber momentan ist das einfach nicht anders zu realisieren.

 

[The_S]

Hast du mal ein Beispiel, wovon Du sprichst?
Wie jedes Framework ist auch Hibernate nicht perfekt. Aber angesichts der komplexen Thematik (Datenbanken), macht Hibernate schon einen extrem guten Job. Zumindest gibts in meinen Augen keine Alternative, oder kennt ihr eine?

Sorry, wir haben unmengen an NamedQuerys in diesem Projekt und sind momentan ein wenig hintendran. Da habe ich leider keine Zein einen konkreten Fall rauszusuchen. Aber wenn mal wieder mehr Zeit ist und dieser Thread nicht bei mir in Vergessenheit geraten sollte, werde ich mich mal auf die Suche machen.

Ansonsten muss ich Slater schon rechtgeben. Hibernate muss nicht in jedem Fall fehlerfrei funktionieren - das macht keine Software und verlangt auch niemand. Aber es sollte keinen korrekten Code doch "Optimierung" verfälschen.

So, ich mach jetzt erstmal Feierabend. Bis Dienstag

 

[SlaterB]

Du schreibst, Hibernate muss in jedem Fall fehlerfrei funktionieren. Wie soll das bitte gehen? Hibernate kann nicht jede Exception der DB im Vorraus berechnen und entsprechend darauf reagieren bzw. sie verhindern.

ist das ein Scherz? habe ich auch geschrieben, dass ein Sortieralgorithmus gegen OutOfMemoryError sicher sein muss oder konkurrierende Veränderung der Objekte zur Laufzeit?
oder muss sich nicht eher ein Sortieralgorithmus genau um seine Sortierung kümmern und Hibernate genau um seine Inserts..
bin etwas sprachlos ob dieser Nachfrage..

Bei DB Statements spielt Performance eine sehr große Rolle. Hibernate optimiert hinsichtlich der Performance, was in diesem Fall Probleme bereitet. Hibernate bietet aber auch eine Lösung mittels flush(). Insofern ist das Problem neutralisiert.

dieser Punkt wäre akzeptabel, etwa wenn das irgendwo in der 500 Seiten-Anleitung von Hibernate oder in der Doku von flush() beschrieben wäre
oder wenn es eine Einstellung gäbe 'lieber sicher statt schnell' so wie die einigermaßen bekannten Isolationslevel einer Transaktion

aber wenn nichtmal ein solcher möglicher konkreter Fehlerfall irgendwo von Hibernate dokumentiert ist,
dann meine ich, muss man doch eher von einem Bug ausgehen

Zumal auch nicht jede DB gleich ist. Bei Oracle gibts z.b. die Möglichkeit, Constraints erst beim Commit der Transaktion zu checken. Da würde o.g. Problem gar nicht auftreten.

ein Grund mehr für Einstellungen,
kein Grund für Fehlerverhalten

zumal ich weiterhin nicht sehe, wieso ein Delete vor oder nach dem Insert etwas optimiert

 

[maki]

Womit wir beim nächsten Problem des Projekts wären. Bei einer sehr alten Anwendung, die über 10 Jahre lang gewachsen ist, wird der Datenbanktreiber nicht mehr offiziell unterstützt. Es ist nur noch eine Frage der Zeit, bis uns das Ding um die Ohren fliegt. Ziel war/ist es jetzt "auf die schnelle" ein anderes Backend für diese Anwendung aufzubauen. Deshalb müssen wir uns an dieser Stelle an die Logik der alten Applikation halten. Bei einer späteren Neuentwicklung der gesamten Anwendung sieht die Welt schon wieder ganz anders aus. Da gebe ich dir dann natürlich recht. Aber momentan ist das einfach nicht anders zu realisieren.

Aha, da liegt der Hase im Pfeffer... retrofitting von Altwanwendungen ist immer nur ein großer Brocken aus Kompromissen, deswegen wollen ja alle zu den sog. Greenfield Projekten

Persönlich bin ich kein Freund davon Hibernate/JPA auf bestehe DB Schema und Klassenmodelle aufzuzwängen, da ist iBatis imho besser geeignet da flexibler (weil kein echtes ORM).

Die von dir angesprochenen Probleme mit JPA sehe ich ähnlich, und mittlerweile ist JPA nicht unumstritten, vor allem wenn man es mit bereits bestehenden ORM Lösungen wie JDO (seit 1999) vergleicht, hinkt es einfach.
Anscheinend wird JPA durch Marktinteressen von RDBMS Herstellern getrieben, soz. durch Politik gertrieben.

Nachtrag: Viele Probleme mit Hibernate (oder ORM im allgemeinen) haben ihre Ursache darin, dass man selbst immer noch zusehr in RDBMS Dimensionen denkt, mit ORM ist die DB zweitrangig, das ORM ist Herr der Daten, und damit auch über die Reihenfolge von irgendwelchen low-level SQL Abfragen

 

[The_S]

Persönlich bin ich kein Freund davon Hibernate/JPA auf bestehe DB Schema und Klassenmodelle aufzuzwängen, da ist iBatis imho besser geeignet da flexibler (weil kein echtes ORM).

Sag das mal unserem Architekten. Ist ja nicht so, dass wir bereits Projekterfahrung mit iBatis haben. Aber nein, SAP und JPA ist das Allheilmittel, weshalb das Projekt mit aller Gewalt in dieses Korsett gezwungen werden muss :noe:

 

[KSG9|sebastian]

Also bestehende Anwendungen auf JPA umzubauen halte ich für fragwürdig.

Nachtrag: Viele Probleme mit Hibernate (oder ORM im allgemeinen) haben ihre Ursache darin, dass man selbst immer noch zusehr in RDBMS Dimensionen denkt, mit ORM ist die DB zweitrangig, das ORM ist Herr der Daten, und damit auch über die Reihenfolge von irgendwelchen low-level SQL Abfragen

Man MUSS in RDBMS-Dimensionen denken. Ein ORM-Framework hilft einem mit einer Datenbank zu kommunizieren, allerdings nimmt es einem das Denken nicht ab. Und genau das ist oft der Grund warum es zu Performanceproblemen kommt.
So nach dem Motto "Die Datenbank, der komische schwarze Kasten im Rechenzentrum, ist mir doch Schnuppe. Was kümmern mich Indizes, Normalisierung, Optimierung von Querys".

In größeren Projekten muss enorm darüber nachgedacht werden wie man z.B. Abfragen macht, lazy-loading ist der nächste Streitfaktor: Sinnvoll eingesetzt ein tolles Feature, falsch eingesetzt führt es nur zu Problemen (n+1-Problem u.s.w.).

Allerdings muss ich vielen hier recht geben, JPA 1.0 hinkt einfach ewig hinterher. JPA 2.0 schafft bei manchen Problemen abhilfe, ist aber imho für Großprojekte nur schwer einsetzbar da einfach sehr viel fehlt.