Transaktionen

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Erstellen und Verwenden von Transaktionen

Transaktionen werden mit DataSource oder EntityManager erstellt. Beispiele:

await myDataSource.transaction(async (transactionalEntityManager) => {
    // execute queries using transactionalEntityManager
})

oder

await myDataSource.manager.transaction(async (transactionalEntityManager) => {
    // execute queries using transactionalEntityManager
})

Alles, was in einer Transaktion ausgeführt werden soll, muss innerhalb eines Callbacks erfolgen:

await myDataSource.manager.transaction(async (transactionalEntityManager) => {
    await transactionalEntityManager.save(users)
    await transactionalEntityManager.save(photos)
    // ...
})

Die wichtigste Einschränkung bei Transaktionen ist: IMMER die bereitgestellte Entity Manager-Instanz verwenden – hier transactionalEntityManager. KEINESFALLS DEN GLOBALEN ENTITY MANAGER VERWENDEN. Alle Operationen MÜSSEN mit dem bereitgestellten transaktionalen Entity Manager ausgeführt werden.

Festlegen von Isolationsstufen

Die Isolationsstufe kann durch Angabe als ersten Parameter festgelegt werden:

await myDataSource.manager.transaction(
    "SERIALIZABLE",
    (transactionalEntityManager) => {},
)

Die Implementierung von Isolationsstufen ist nicht einheitlich für alle Datenbanken. Jeder Treiber deklariert, welche Stufen er unterstützt, und TypeORM wirft einen Fehler, wenn Du eine nicht unterstützte Stufe anforderst.

Driver	Supported isolation levels
MySQL / MariaDB	READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE
PostgreSQL	READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE
CockroachDB	READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE
SQL Server	READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE, SNAPSHOT
Oracle	READ COMMITTED, SERIALIZABLE
SAP HANA	READ COMMITTED, REPEATABLE READ, SERIALIZABLE
SQLite	READ UNCOMMITTED*, SERIALIZABLE
Spanner	READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE

* SQLites READ UNCOMMITTED ist nur wirksam, wenn der shared-cache mode aktiviert ist. Im Standardmodus verwendet SQLite immer SERIALIZABLE-Isolation, unabhängig von der Einstellung.

SQL Server unterstützt auch das Setzen einer Standard-Isolationsstufe über DataSource-Optionen (isolationLevel und connectionIsolationLevel), aber diese unterliegen einer Einschränkung des Upstream-Pools. Isolationsstufen pro Transaktion sind davon nicht betroffen.

QueryRunner zur Steuerung einzelner Datenbankverbindungen

Ein QueryRunner stellt eine einzelne Datenbankverbindung bereit. Transaktionen werden über Query Runner organisiert. Pro Query Runner kann nur eine Transaktion aktiv sein. Sie können manuell eine Query Runner-Instanz erstellen und Transaktionen steuern: Beispiel:

// create a new query runner
const queryRunner = dataSource.createQueryRunner()

// establish real database connection using our new query runner
await queryRunner.connect()

// now we can execute any queries on a query runner, for example:
await queryRunner.query("SELECT * FROM users")

// we can also access entity manager that works with connection created by a query runner:
const users = await queryRunner.manager.find(User)

// lets now open a new transaction:
await queryRunner.startTransaction()

try {
    // execute some operations on this transaction:
    await queryRunner.manager.save(user1)
    await queryRunner.manager.save(user2)
    await queryRunner.manager.save(photos)

    // commit transaction now:
    await queryRunner.commitTransaction()
} catch (err) {
    // since we have errors let's rollback changes we made
    await queryRunner.rollbackTransaction()
} finally {
    // you need to release query runner which is manually created:
    await queryRunner.release()
}

QueryRunner bietet drei Transaktionssteuerungsmethoden:

• startTransaction - startet eine neue Transaktion innerhalb der Query Runner-Instanz.

• commitTransaction - committet alle Änderungen, die mit der Query Runner-Instanz durchgeführt wurden.

• rollbackTransaction - rollt alle Änderungen zurück, die mit der Query Runner-Instanz durchgeführt wurden.

Mehr Details unter Query Runner.