Dateien und Transaktion

Worum es geht

Ein Datei-Modell hat zwei Teile: den Datensatz in der Datenbank und den Inhalt im Dateispeicher. Siehe Was ein Datei-Modell ist.

Die Datenbank hat eine Transaktion, der Dateispeicher nicht. CDMS lässt den Dateispeicher deshalb der Datenbank folgen: Während die Anfrage läuft, wird jede Änderung am Inhalt nur vorbereitet. Wirksam wird sie erst, wenn die Datenbank den Datensatz festgeschrieben hat (Commit). Scheitert die Anfrage vorher, wirft CDMS das Vorbereitete weg.

Vorbereiten und wirksam werden

Jede Änderung am Inhalt hat zwei Schritte:

Schritt	wann	was passiert	sichtbar?
Vorbereiten	während der Anfrage	Ein hochgeladener Inhalt wird unter einem privaten Namen neben seinen Platz gelegt. Für einen Rollback wird die gewünschte Version dorthin kopiert. Ein Löschen wird nur vorgemerkt. `fileSize`, `mimeType` und `fileVersion` stehen danach schon fest.	nein
Wirksam werden	nach dem Commit	Der bisherige Inhalt wird bei auditierten Modellen als Version aufbewahrt, dann wird der vorbereitete Inhalt mit einem einzigen Umbenennen an seinen Platz gehoben. Ein vorgemerktes Löschen entfernt Inhalt und Versionen.	ja

Der Datensatz braucht fileSize, mimeType und fileVersion schon beim Speichern. Deshalb liest CDMS sie aus dem vorbereiteten Inhalt, der Byte für Byte dem entspricht, der später aktuell wird.

Der Ablauf eines Uploads

sequenceDiagram
    participant C as Client
    participant D as CDMS
    participant F as Dateispeicher
    participant DB as Datenbank
    C->>D: POST /fileasset/create/upload (Datensatz + Datei)
    D->>D: Rolle prüfen
    D->>F: Inhalt vorbereiten (privater Name, noch nicht sichtbar)
    D->>D: Before-Hooks, Validierung
    D->>DB: Datensatz speichern, flush
    D->>DB: zurücklesen
    D->>DB: COMMIT
    D->>F: Inhalt wirksam machen (umbenennen)
    D-->>C: 200 mit dem Datensatz

Das Umbenennen passiert in einem Schritt. Wer die Datei gerade herunterlädt, bekommt deshalb immer einen vollständigen Inhalt, nie einen halb geschriebenen.

Wo es scheitern kann

Ein Upload mit Fehler

ErfolgFehler beim VorbereitenFehler nach dem VorbereitenFehler nach dem Commit

Wann: Alle Schritte gelingen.

1

CDMS→File storage
bereitet den Inhalt vor
2

CDMS→Database
speichert den Datensatz, Commit
3

CDMS→File storage
macht den Inhalt wirksam

Ergebnis: Datensatz und Inhalt passen zusammen.

Wann: Der Dateispeicher kann den Inhalt nicht übernehmen, etwa weil das Volume voll ist.

1

CDMS→File storage
Vorbereiten scheitert
2

CDMS→Client
500 file-not-saved, die Datenbank wird zurückgerollt

Ergebnis: Nichts ist gespeichert, weder Datensatz noch Inhalt.

Wann: Der Inhalt ist vorbereitet, dann scheitert etwas anderes: Validierung (422), Rolle eines Kindes (403), ein Hook, eine Datenbankregel.

1

CDMS→File storage
bereitet den Inhalt vor
2

CDMS
ein späterer Schritt scheitert
3

CDMS→Database
rollt zurück
4

CDMS→File storage
wirft den vorbereiteten Inhalt weg
5

CDMS→Client
Fehlerantwort

Ergebnis: Datenbank und Dateispeicher sind unverändert. Beim Ersetzen ist der bisherige Inhalt weiter aktuell.

Wann: Der Datensatz ist festgeschrieben, aber das Umbenennen im Dateispeicher scheitert. Das ist sehr selten, weil nur noch ein Umbenennen im selben Verzeichnis fehlt.

1

CDMS→Database
Commit
2

CDMS→File storage
Umbenennen scheitert
3

CDMS→Client
500 file-not-saved

Ergebnis: Der Datensatz ist gespeichert, der Inhalt ist noch der alte. Der vorbereitete Inhalt bleibt im Speicher liegen, er ist die einzige Kopie. Die Anfrage erneut zu schicken, bringt beides wieder zusammen.

Entscheidungstabelle

Datenbank und Dateispeicher nach einer Anfrage

Operation	Anfrage erfolgreich?	Stand danach
Anlegen mit Datei	ja	Datensatz und Inhalt vorhanden
Anlegen mit Datei	nein	weder Datensatz noch Inhalt
Inhalt ersetzen	ja	neuer Inhalt aktuell, bei auditierten Modellen der alte als Version
Inhalt ersetzen	nein	Datensatz und bisheriger Inhalt unverändert
Löschen	ja	Datensatz und Inhalt samt Versionen weg
Löschen	nein	Datensatz, Inhalt und Versionen bleiben
eine der drei	Commit ja, Umbenennen oder Löschen im Speicher nein	Fehlerantwort; der Datensatz ist neu, der Speicher noch alt

Zum Löschen siehe Datei-Modelle löschen, zum Zurücksetzen Rollback bei Dateien. Beide folgen demselben Muster.

Gleichzeitige Uploads

Zwei Anfragen, die gleichzeitig denselben Datensatz mit neuem Inhalt beschreiben, würden im Speicher nacheinander umbenennen, und der spätere Inhalt würde still gewinnen. Deshalb sperrt CDMS den Datensatz, bevor es den Inhalt vorbereitet. Die zweite Anfrage bekommt 409 und hat noch nichts in den Speicher gelegt. Siehe Gleichzeitige Änderungen.

Wie du damit umgehst

Wie es weitergeht

Die Klammer um die Datenbank: Ein Request, eine Transaktion
Hochladen im Detail: Hochladen
Ablage im Speicher: Ablage und Mandantentrennung im Speicher