Spring @Transactional - Isolierung, Vermehrung

Gute Frage, wenn auch nicht trivial zu beantworten.

Vermehrung

Definiert, wie Transaktionen beziehen sich auf die jeweils anderen. Gemeinsame Optionen

• Required: Code wird immer in einer Transaktion ausgeführt werden. Erstellen Sie eine neue Transaktion oder wieder verwenden, wenn verfügbar.
• Requires_new: Code läuft immer in einer neuen Transaktion. Auszusetzen aktuellen Transaktion, wenn eine vorhanden ist.

Isolation

Definiert die Daten-Vertrag zwischen den Transaktionen.

• Read Uncommitted: Können dirty reads
• Read Committed: Nicht erlaubt, dirty reads
• Repeatable Read: Wenn eine Zeile gelesen wird zweimal in der gleichen transaciton, das Ergebnis wird immer das gleiche
• Serializable: Führt alle Transaktionen in einer Sequenz

Den verschiedenen Ebenen haben verschiedene performance-Eigenschaften in einem multi-threaded-Anwendung. Ich denke, wenn Sie verstehen, die dirty reads Konzept werden Sie in der Lage, wählen Sie eine gute option.

Beispiel, wenn ein dirty read auftreten können

  thread 1   thread 2      
      |         |
    write(x)    |
      |         |
      |        read(x)
      |         |
    rollback    |
      v         v 
           value (x) is now dirty (incorrect)

So ein sane-Standard (wenn eine solche beansprucht werden kann) könnte Read Comitteddas können Sie nur-lese-Werte, die bereits übergebene, die von anderen Transaktionen ausgeführt, in Kombination mit einem übertragungsgrad von Required. Dann können Sie von dort aus arbeiten, wenn Sie die Anwendung hat andere Bedürfnisse.

Einem praktischen Beispiel, wo eine neue Transaktion wird immer dann erstellt werden, wenn die Eingabe der provideService routine und abgeschlossen werden beim verlassen.

public class FooService {
    private Repository repo1;
    private Repository repo2;

    @Transactional(propagation=Propagation.REQUIRES_NEW)
    public void provideService() {
        repo1.retrieveFoo();
        repo2.retrieveFoo();
    }
}

Hatten wir verwendet Required anstatt die Transaktion offen bleibtwenn die Transaktion bereits geöffnet ist, wenn die Eingabe der routine.
Beachten Sie auch, dass das Ergebnis einer rollback anders sein könnte, wie mehrere Hinrichtungen teilnehmen kann, in der gleichen Transaktion.

Können wir leicht überprüfen Sie das Verhalten mit einem test und sehen Sie, wie sich die Ergebnisse unterscheiden mit Vermehrung Ebenen

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:/fooService.xml")
public class FooServiceTests {

    private @Autowired TransactionManager transactionManager;
    private @Autowired FooService fooService;

    @Test
    public void testProvideService() {
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
        fooService.provideService();
        transactionManager.rollback(status);
        //assert repository values are unchanged ... 
}

Mit einem übertragungsgrad von

• Requires new würden wir erwarten, dass fooService.provideService() war NICHT rollte zurück, da er Sie geschaffen, eigene sub-Transaktion.

• Required wir würden erwarten, dass alles zurückgesetzt wurde und backing-store unverändert.

InformationsquelleAutor der Antwort

Genug Erklärung zu jedem parameter angegeben wird, durch andere Antworten; Aber Sie bat um ein reales Beispiel, hier ist der eine, klärt die Einsatzmöglichkeiten von verschiedenen Vermehrung Optionen:

Angenommen, Sie sind verantwortlich für die Durchführung einer Anmeldung service, in denen eine Bestätigung per e-mail an den Benutzer gesendet wird. Sie kommen mit zwei service-Objekten, eines für die Einschreibung den Benutzer und eine für senden e-mails, die letztere ist aufgerufen, in die erste. Zum Beispiel so etwas wie dieses:

/* Sign Up service */
@Service
@Transactional(Propagation=REQUIRED)
class SignUpService{
 ...
 void SignUp(User user){
    ...
    emailService.sendMail(User);
 }
}

/* E-Mail Service */
@Service
@Transactional(Propagation=REQUIRES_NEW)
class EmailService{
 ...
 void sendMail(User user){
  try{
     ... //Trying to send the e-mail
  }catch( Exception)
 }
}

Haben Sie möglicherweise bemerkt, dass der zweite service ist der Vermehrung geben REQUIRES_NEW und darüber hinaus die Chancen sind, wirft er eine Ausnahme (SMTP-server down ,ungültige e-mail-oder anderen Gründen).Sie wollen wahrscheinlich nicht den gesamten Prozess zum roll-back, wie das entfernen der Benutzerinformationen aus einer Datenbank oder anderen Dingen; daher rufen Sie den zweiten Dienst in einer separaten Transaktion.

Zurück zu unserem Beispiel, dieses mal sind Sie besorgt über die Sicherheit der Datenbanken, so definieren Sie die DAO-Klassen in dieser Weise:

/* User DAO */
@Transactional(Propagation=MANDATORY)
class UserDAO{
 //some CRUD methods
}

Bedeutung, dass, wenn ein DAO-Objekt, und somit einen potentiellen Zugriff auf db ist angelegt, die wir benötigen, um Ihnen zu versichern, dass der Anruf wurde von innen an einer unserer Dienstleistungen, was bedeutet, dass eine live-Transaktion sollte vorhanden sein; ansonsten tritt eine Ausnahme auf.Deshalb ist die Ausbreitung der Art ZWINGEND.

InformationsquelleAutor der Antwort ye9ane

Du fast nie nutzen wollen Read Uncommited da es nicht wirklich ACID konform. Read Commmited ist ein guter Standard der Ausgangspunkt. Repeatable Read wird wohl nur benötigt, reporting -, rollup-oder aggregation-Szenarien. Beachten Sie, dass viele DBs postgres enthalten eigentlich nicht unterstützen, Repeatable Read, müssen Sie Serializable statt. Serializable ist nützlich für die Dinge, die Sie wissen müssen, geschehen völlig unabhängig von allem anderen; es ist wie synchronized in Java. Serializable geht hand in hand mit REQUIRES_NEW Vermehrung.

Benutze ich REQUIRES für alle Funktionen ausführen, UPDATE-oder DELETE-Abfragen sowie "service" level-Funktionen. Für DAO-level-Funktionen, die nur ausgeführt werden Selektiert, ich verwende SUPPORTS die Teilnahme an einem TX wenn man bereits begonnen hat (d.h. aus einem Webdienst aufgerufen wird function).

InformationsquelleAutor der Antwort AngerClown

Habe ich outerMethod,method_1 und method_2 mit unterschiedlichen Vermehrung-Modus.

Unten ist die Ausgabe für verschiedene Vermehrung-Modus.

• Äußeren Methode

  @Transactional
  @Override
  public void outerMethod() {
      customerProfileDAO.method_1();
      iWorkflowDetailDao.method_2();
  }

• Method_1

  @Transactional(propagation=Propagation.MANDATORY)
  public void method_1() {
      Session session = null;
      try {
          session = getSession();
          Temp entity = new Temp(0l, "XXX");
          session.save(entity);
          System.out.println("Method - 1 Id "+entity.getId());
      } finally {
          if (session != null && session.isOpen()) {
          }
      }
  }

• Method_2

  @Transactional()
  @Override
  public void method_2() {
      Session session = null;
      try {
          session = getSession();
          Temp entity = new Temp(0l, "CCC");
          session.save(entity);
          int i = 1/0;
          System.out.println("Method - 2 Id "+entity.getId());
      } finally {
          if (session != null && session.isOpen()) {
          }
      }
  }

  1. • outerMethod - Ohne Transaktion
     • method_1 - Vermehrung.OBLIGATORISCH) -
     • method_2 - Transaction-annotation nur
     • Ausgabe: method_1 werfen eine Ausnahme, dass keine der vorhandenen Transaktion
  2. • outerMethod - Ohne Transaktion
     • method_1 - Transaction-annotation nur
     • method_2 - Vermehrung.OBLIGATORISCH)
     • Ausgabe: method_2 werfen eine Ausnahme, dass keine der vorhandenen Transaktion
     • Ausgabe: method_1 wird weiterhin die Aufzeichnung in der Datenbank.
  3. • outerMethod - Mit der Transaktion
     • method_1 - Transaction-annotation nur
     • method_2 - Vermehrung.OBLIGATORISCH)
     • Ausgabe: method_2 wird weiterhin die Aufzeichnung in der Datenbank.
     • Ausgabe: method_1 wird weiterhin die Aufzeichnung in der Datenbank.
       -- Hier die Wichtigsten Äußeren vorhandene Transaktion, sowohl für die Methode 1 und 2
  4. • outerMethod - Mit der Transaktion
     • method_1 - Vermehrung.OBLIGATORISCH) -
     • method_2 - Transaktion nur Anmerkungen und wirft Ausnahme
     • Ausgabe: keine Aufnahme anhalten, in der Datenbank-rollback durchgeführt.
  5. • outerMethod - Mit der Transaktion
     • method_1 - Vermehrung.REQUIRES_NEW)
     • method_2 - Vermehrung.REQUIRES_NEW) und wirft 1/0 Ausnahme
     • Ausgabe: method_2 wird, wirft Ausnahme, so method_2 Datensatz nicht beibehalten.
     • Ausgabe: method_1 wird weiterhin die Aufzeichnung in der Datenbank.
     • Ausgang: Es wird kein rollback für method_1

InformationsquelleAutor der Antwort NIrav Modi

Stellt eine Transaktion eine Einheit von Arbeit mit einer Datenbank.

Im Frühjahr TransactionDefinition - Schnittstelle, die definiert, Spring-konforme Transaktion Eigenschaften. @Transactional annotation beschreibt, Transaktions-Attribute auf eine Methode oder Klasse.

@Autowired
private TestDAO testDAO;

@Transactional(propagation=TransactionDefinition.PROPAGATION_REQUIRED,isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED)
public void someTransactionalMethod(User user) {

  //Interact with testDAO

}

Vermehrung (Reproduktion) : wird verwendet für den inter-Transaktions-Verhältnis. (Analog zu java inter-thread-Kommunikation)

+-------+---------------------------+------------------------------------------------------------------------------------------------------+
| value |        Propagation        |                                             Description                                              |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+
|    -1 | TIMEOUT_DEFAULT           | Use the default timeout of the underlying transaction system, or none if timeouts are not supported. |
|     0 | PROPAGATION_REQUIRED      | Support a current transaction; create a new one if none exists.                                      |
|     1 | PROPAGATION_SUPPORTS      | Support a current transaction; execute non-transactionally if none exists.                           |
|     2 | PROPAGATION_MANDATORY     | Support a current transaction; throw an exception if no current transaction exists.                  |
|     3 | PROPAGATION_REQUIRES_NEW  | Create a new transaction, suspending the current transaction if one exists.                          |
|     4 | PROPAGATION_NOT_SUPPORTED | Do not support a current transaction; rather always execute non-transactionally.                     |
|     5 | PROPAGATION_NEVER         | Do not support a current transaction; throw an exception if a current transaction exists.            |
|     6 | PROPAGATION_NESTED        | Execute within a nested transaction if a current transaction exists.                                 |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+

Isolation : Isolation ist eines der ACID (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit) Eigenschaften von Datenbank-Transaktionen. Isolation bestimmt, wie die Transaktion Integrität ist sichtbar für andere Benutzer und Systeme. Es nutzt für resource-locking, d.h. concurrency control, stellen Sie sicher, dass nur eine Transaktion kann auf die Ressource an einem bestimmten Punkt.

Sperren Wahrnehmung: isolation level bestimmt die Dauer, die sperren gehalten werden.

+---------------------------+-------------------+-------------+-------------+------------------------+
| Isolation Level Mode      |  Read             |   Insert    |   Update    |       Lock Scope       |
+---------------------------+-------------------+-------------+-------------+------------------------+
| READ_UNCOMMITTED          |  uncommitted data | Allowed     | Allowed     | No Lock                |
| READ_COMMITTED (Default)  |   committed data  | Allowed     | Allowed     | Lock on Committed data |
| REPEATABLE_READ           |   committed data  | Allowed     | Not Allowed | Lock on block of table |
| SERIALIZABLE              |   committed data  | Not Allowed | Not Allowed | Lock on full table     |
+---------------------------+-------------------+-------------+-------------+------------------------+

Lesen Wahrnehmung: die folgenden 3 Arten von wichtigen Problemen Auftritt:

• Dirty reads : liest nicht gespeicherte Daten von einem anderen tx - (transaction).
• Nicht-wiederholbare Lesevorgänge : liest begangen UPDATES von einem anderen tx.
• Phantom liest : liest begangen INSERTS - und/oder DELETES von einem anderen tx

Isolation levels mit verschiedenen Arten von liest:

+---------------------------+----------------+----------------------+----------------+
| Isolation Level Mode      |  Dirty reads   | Non-repeatable reads | Phantoms reads |
+---------------------------+----------------+----------------------+----------------+
| READ_UNCOMMITTED          | allows         | allows               | allows         |
| READ_COMMITTED (Default)  | prevents       | allows               | allows         |
| REPEATABLE_READ           | prevents       | prevents             | allows         |
| SERIALIZABLE              | prevents       | prevents             | prevents       |
+---------------------------+----------------+----------------------+----------------+

für Beispiele

InformationsquelleAutor der Antwort Premraj