wake-up-neo.com

Warum wird "hibernate.connection.autocommit = true" in Hibernate nicht empfohlen?

In der Hibernate-API gibt es eine Eigenschaft hibernate.connection.autocommit , die auf true gesetzt werden kann. 

Aber in der API haben sie erwähnt, dass es nicht empfohlen wird, es so zu setzen:

Aktiviert die Autocommit-Funktion für JDBC-Pool-Verbindungen (wird nicht empfohlen ).

Warum wird es nicht empfohlen? Was sind die negativen Auswirkungen, wenn diese Eigenschaft auf true gesetzt wird?

19
Ponmudi VN

Der Autocommit-Wert ist standardmäßig false, daher muss die Transaktion explizit festgeschrieben werden. Dies kann der Grund dafür sein, dass die Änderungen nicht in der Datenbank angezeigt werden. Andernfalls können die Änderungen mit Flush vor dem Festschreiben erzwungen werden.

Wenn Sie die Sitzung schließen, wird sie implizit in der Datenbank festgeschrieben [abhängig von der Implementierung].

Wenn Sie kaskadierende Transaktionen haben und ein Rollback für Atomicity durchführen müssen, müssen Sie die Kontrolle über Transaktionen haben. In diesem Fall sollte autocommit false sein.

Legen Sie autocommit entweder als true fest oder behandeln Sie Transaktionen explizit.

Hier ist eine gute Erklärung dazu.

Hibernate-Forum im Zusammenhang damit.

Stackoverflow Frage drauf.

13
user3145373 ツ

Meines Wissens ist es so, dass bei einem Hibernate-Autocommits ein Flush, der teilweise ausfällt, nicht zurückgesetzt wird. Sie haben ein unvollständiges/defektes Objektdiagramm.

Wenn Sie eine Verbindung mit Autocommit für etwas wünschen, können Sie eine neu erstellte Session immer auspacken, um die zugrunde liegende JDBC-Verbindung (setAutocommit(true)) darauf zu erhalten, Ihre Arbeit über JDBC-APIs setAutocommit(false) auszuführen und die Sitzung zu schließen. Ich würde nicht empfehlen, dies auf einer Session zu tun, die schon etwas getan hat.

6
Craig Ringer

Alle Datenbankanweisungen werden im Kontext einer physischen Transaktion ausgeführt, auch wenn wir Transaktionsgrenzen nicht explizit deklarieren (BEGIN/COMMIT/ROLLBACK).

Wenn Sie die Transaktionsgrenzen nicht deklarieren, muss jede Anweisung in einer separaten Transaktion ausgeführt werden. Dies kann sogar dazu führen, dass pro Anweisung eine Verbindung geöffnet und geschlossen wird.

Wenn Sie einen Service als @Transactional deklarieren, erhalten Sie eine Verbindung für die gesamte Transaktionsdauer. Alle Anweisungen verwenden diese einzige Isolationsverbindung. Dies ist viel besser als explizite Transaktionen überhaupt nicht zu verwenden. Bei großen Anwendungen haben Sie möglicherweise viele gleichzeitige Anforderungen und die Anforderungsrate für das Erfassen von Datenbankverbindungen wird reduziert Sie verbessern auf jeden Fall Ihre allgemeine Anwendungsleistung.

Die Faustregel lautet also:

  1. Wenn Sie schreibgeschützte Transaktionen haben, die nur eine Abfrage ausführen, können Sie die automatische Festschreibung für diese aktivieren.

  2. Wenn Sie Transaktionen mit mehr als einer Anweisung haben, müssen Sie das automatische Festschreiben deaktivieren, da alle Vorgänge in einer einzelnen Arbeitseinheit ausgeführt werden sollen und Sie keinen zusätzlichen Druck auf Ihren Verbindungspool ausüben möchten.

5
Vlad Mihalcea

Verwenden Sie nicht das Session-per-Operation-Antipattern: Öffnen und schließen Sie keine Session für jeden einfachen Datenbankaufruf in einem einzelnen Thread. Gleiches gilt für Datenbanktransaktionen. Datenbankaufrufe in einer Anwendung werden mit einer geplanten Sequenz ausgeführt. Sie sind in atomare Arbeitseinheiten gruppiert. Dies bedeutet auch, dass das automatische Festschreiben nach jeder einzelnen SQL-Anweisung in einer Anwendung unbrauchbar ist, da dieser Modus für die Ad-hoc-Arbeit mit der SQL-Konsole vorgesehen ist. Der Ruhezustand deaktiviert den Auto-Commit-Modus sofort oder erwartet, dass der Anwendungsserver ihn deaktiviert. Datenbanktransaktionen sind niemals optional. Die gesamte Kommunikation mit einer Datenbank muss innerhalb einer Transaktion erfolgen. Das Auto-Commit-Verhalten zum Lesen von Daten sollte vermieden werden, da viele kleine Transaktionen wahrscheinlich keine bessere Leistung erbringen als eine klar definierte Arbeitseinheit. Letzteres ist auch wartungsfreundlicher und erweiterbar.

Weitere Informationen zu diesem Thema finden

2
newday