Wo liegt denn überhaupt das Problem?
Aus Objektsicht ist „alles ok“. Die Persistierung erfolgt in einer dummen Datenbank und wenn Objektdaten geschrieben werden, deren Verweise ins Nichts gehen, bleiben halt Leichen übrig. Das würde bedeuten, dass auch aus Objektsicht eine Speicherung nicht erfolgreich oder nicht erfolgreich war. Ziemlich transparent. Eben etwas eingetragen, jetzt ist es futsch. Pech.
Na klar, es entstehen in der DB viele Leichen. Diese Leichen fressen Platz. So what?!
Trotzdem: Die Klassenhierarchie hat wegen der fehlerhaften Speicherung eben auch ein Leck. Sie muss erneut, richtig speichern. Das muss der User durchführen oder der Entwickler verbessern oder erforschen. Das Problem bleibt aber ungefähr da, wo es entsteht. Und in der entsprechenden Verantwortung.
So mal als Gedankenspiel:
Erst in dem Moment, wo ich „hintenrum“, in der DB für Reports, Batchverarbeitung oder solche Sachen Abfragen und Operationen durchführe, die „neben“ dem Objektmodell irgendwelche Dinge tun und wenn ich dabei die Klassenhierarchie „von unten“ anfasse, tote Objekte verarbeite, summiere usw. erst dann habe ich ein echtes Problem. Es kommt nur Müll raus. Im schlimmsten Fall nicht mal offensichtlicher Müll, nur wenn man genau hinschaut, passen Details aus der „Objekt App“ nie zu den DB Reports…
An der Stelle muss ich mich entscheiden, mache ich die oben genannten Jobs mit dem gleichen Klassenmodell „von oben“, habe irgendwo ein paar Leichen und bin „glücklich“ oder fange ich einen aussichtslosen Kampf an?
Fazit:
Wenn es „nur“ darum geht, irgendwelchen fehlerhaften Serialisierungsprozessen auf die Schliche zu kommen, Entwickler zu ermahnen, Entwicklern den produzierten Schrott zu zeigen, dann kann ich das mit ein paar Select Statements exemplarisch, worst case (größte Müllhaufen zuerst) und zyklisch immer wieder durchführen. Bis es behoben ist. Wenn ich aber auf Commit Ebene in laufende Prozesse eingreife (und wenn ich dabei selbst vielleicht auch mal irgendwo einen Fehler mache), dann kann das in der Produktion ganz schön nach hinten los gehen. Im Zweifel ist die Programmierung so schlecht, dass ein Commit/Rollback noch nicht mal im Programm hoch kommt als Fehler:
try
persist
except
do nothing
end
Ein echter Anwender wird dabei wahnsinnig, eine Maschine interessierts auch nicht, die Daten landen schön im Nirvana und zwar komplett (statt gespeichert zu werden, plus ein paar Zombies zu produzieren)
Würde ich mir sehr genau überlegen, ob ich so einen Forced Rollback Mechanismus anlege. Wenn es ein großes System ist, besteht auch noch die Gefahr, dass die Trigger das Laufzeitverhalten stark beeinflussen.
Lieber erst mal ein paar Select Statements zur Prüfung bauen, daraus Monitoring Views anlegen und ständig Reporten, von wo welcher Dreck rein kommt. Kann man auch schön ein Dashboard draus bauen, Grafana oder so. Dann die Firmenseite hacken und es als Landingpage einrichten. Dann mit den Leuten reden und Lösegeldforderungen stellen.