Vermeiden Sie Transaktionsvergiftung DDL und härten Multi-Pod-Rennen

FixSecurityService
Verschifft
20. April 2026 um 20:43 UTC
Autor
Kamo
Ausschuss
d3249b4

Die vorherige Selbstheilung setzte DDL in eine @Transactional syncAll(). Wenn ein ALTER TABELLE ADD CONSTRAINT auf eine bestehende Einschränkung abgefeuert (normaler Fall nach dem ersten booten, oder die verlierende pod in einem Multi-Pod-Rennen), runIdempotent verschluckt die Java Ausnahme - aber die umgebende DB-Transaktion wurde in einem abgebrochenen Zustand gelassen. Jeder nachfolgende JPA-Anruf wird dann Hit-"aktuelle Transaktion abgebrochen, Befehle ignoriert bis Ende der Transaktion Block., wobei die pod nach unten auf jeden Neustart. Änderungen: - syncAll() ist nicht mehr @Transactional. Jede Phase läuft mit ihren eigenen Autonomie: DDL auto-commits pro Statement außerhalb jedes Spring TX, also ein Ein-Statement-Versagen kann nichts vergiften. - sicherstellenUniqueConstraint() prüft jetzt pg_constraint vor dem Versuch von ADD, so dass der Fehler "bereits existiert" nie auf normale Neustarts feuert. - Selbsteinspritzung (@Lazy self) so die Sub-Methoden '@Transactional tatsächlich Brände über den Spring Proxy (der vorherige this.syncOrgRoleRights() call Umgangen von AOP). - Dokumentiert die gleichzeitige Zynanalyse: DDL serialisiert von CRDB, DELETEs idempotent, fügt Race-Safe über ON CONFLICT DO NOTHING.

Alle Änderungen

Wie, was Sie sehen Versand?

Jedes dieser Updates landet automatisch in Ihrem Arbeitsbereich. Starten Sie frei und beobachten Sie es Woche für Woche wachsen.

Free Forever startenPreisgestaltung anzeigen