Transaction Isolation Levels überarbeiten
Why
Im Zustelldienst wird an sehr vielen Stellen @Transactional(isolation = Isolation.REPEATABLE_READ)
verwendet.
Die historischen Gründe dafür waren:
- Jede direkte oder transitive Verwendung von Attachment und ReplyAttachment (DB: oid => Entity: byte[]) hat dies nötig gemacht, weil sonst der Fehler "Large Objects may not be used in auto-commit mode." auftrat. Nach dem Merge von #1574 (closed) ist dieses aber nicht mehr nötig.
- Teilweise hat ineffizienter, 2-stufiger Pagination-Code eine gewisse Berechtigung dafür dargestellt, das Ergebnis konsistent zu halten. Dieser Code wurde aber schon mit #1590 abgelöst.
- Sicherlich sind manche Stellen schlichtweg durch copy-paste entstanden.
Die Probleme sind:
- Noise im Code
- Aufgrund des aggressiveren Lockings in der DB erleiden wir Performance-Einbußen
- Es werden LockAcquisitionExceptions mit "ERROR: could not serialize access due to concurrent update" provoziert (wie in den Logs von TEST zu erkennen).
Siehe auch:
- https://en.wikipedia.org/wiki/Isolation_(database_systems)
- https://stackoverflow.com/questions/50797097/postgres-could-not-serialize-access-due-to-concurrent-update
Acceptance criteria
-
Alle @Transactional-Annotationen wurden auf Sinnhaftigkeit überprüft -
Wo immer es möglich ist, wird @Transactional (ohne Argumente) verwendet, was READ_COMMITTED entspricht. Dies kann ggf. sogar auf Klassen-Level geschehen, wenn für alle Methoden der Klasse dieselbe Logik gelten soll.
Implementation plan (to be completed by the developer)
-
Definition of Done was checked.
Edited by Hendrik Kamp