einfache Persistenz ist eine Illusion

die Persistenz bildet eine Schattendatenbank zwischen der Anwendung
und der eigentlichen Datenbank. Das wird problematisch, sobald
mehrere Objekte modifiziert/erzeugt/geloescht werden und diese
Aenderungen in die Datenbank uebertragen werden sollen. Sollte ja in
einer Transaktion passieren, die fehlschlagen kann, je nach
angewandter Locking-Strategie. Evt. ist die Transaktion auch zu
gross, weil in einer Schleife zu viele Objekte (evt. ungewollt)
modifiziert wurden. Worauf die Anwendung angemessen reagieren muss,
ohne den Anwender zu frustrieren. Auch können mehrere Instanzen der
Anwendung, die ihre eigene Persistenzschicht haben und von sich aus
nichts voneinander wissen, sich gegenseitig lahmlegen. Dann kommen
Techniken wie globale Objekt-Identität und
kooperierende/kommunizierende Persistenzlevel zum Einsatz. Der
unbedarfte Programmierer kann damit ohne weiteres das Netzwerk
lahmlegen mit einem Notification Sturm. Also muss man, will man eine
Persistenztechnik einsetzen, deren interne Technik kennen und sich
wie bei der RDB Programmierung mit den Themen Transaktionen,
Serialisierung, Locking, Intanzen-Kommunikation und problemgerechte
Modellierung des Datenbanklayouts kümmern. Wozu dann noch eine
Persitenztechnik? Einen SQL-Abstraction Layer finde ich da
praktischer. Ist einfacher, direkter, kontrollierbarer. Eine RDB
bleibt eine RDB, auch durch einen Persistenzlayer hindurch.