Persistenz

Für Persistenz gibt es zahlreiche Definitionen - recht einfach, umfassend und allgemeingültig ist die von Booch (Object-Oriented Design):

``Persistence is the property of an object through which its existence transcends time (i.e. the object continues to exist after its creator ceases to exist) and/or space (i.e. the object's location moves from the address space in which it was created).''

Leider beschränken sich viele Definitionen nur auf den ersten Teil und ignorieren die Möglichkeit, daß Objekte auch von einem Adreßraum zum anderen wandern können.

Traditionell haben sich viele Programme selbst um das Sichern und Einlesen ihrer Daten gekümmert. Allerdings ist damit ein erheblicher Programmieraufwand verbunden, viele Fehlermöglichkeiten kommen dadurch hinzu und diese Methode ist völlig ungeeignet in einem Umfeld, bei dem keine einzelne Instanz mehr ohne weiteres alle Daten eines Objektes kennt.

Zur Unterstützung der Persistenz gibt es eine Reihe von Ansätzen:

Persistenz auf Basis von Spracherweiterungen:

Bei zahlreichen klassischen Programmiersprachen wurde das Typsystem in orthogonaler Weise in Richtung von Persistenz und Datenbanken (insbesondere relationale Datenbanken) erweitert. Prominent sind hier insbesondere Pascal/R (Joachim W. Schmidt und andere) mit den Nachfolgern Modula/R und DBPL und E (auf C++ aufbauend von Richardson und anderen). Diese Lösungen bestechen insbesondere in ihrer Eleganz im Vergleich zu den herzlich verunglückten Embedded-SQL-Varianten. Trotz der Eleganz sind die Möglichkeiten sehr beschränkt: Es werden die Limitierungen relationaler Datenbanken übernommen (dynamische Datenstrukturen müssen entsprechend abgebildet werden) und die Verknüpfung mit einer konkreten Datenbank erlaubt auch nicht viel Flexibilität.

Persistenz auf Basis von Systembibliotheken:

Viele Lösungen verzichten auf die Erweiterung der Sprache und fügen statt dessen Module oder Klassen hinzu, die alle notwendigen Operationen definieren. Die Implementierung dieser Module oder Klassen hängt weitgehend von den internen Speicherverwaltungsstrukturen ab, die vom Übersetzer generiert worden sind. Dieser Ansatz wird von der großen Mehrheit der objekt-orientierten Programmiersysteme verwendet wie z.B. bei ISE Eiffel, Modula-3 oder BETA.

Der Hauptnachteil liegt in der fehlenden Portabilität: Die Persistenz als unterstützte Eigenschaft ist nicht in der Sprachdefinition vorgesehen und somit wird die Persistenz in jeweils unterschiedlichen Formen implementiert, die wegen ihrer Systemabhängigkeit nicht auf andere Systeme übertragen werden können.

Typischerweise sichern diese Systeme nicht nur ein einzelnes Objekt, sondern analog zur tiefen Kopie (siehe §5.2.1) auch alle davon abhängigen Objekte. Dies ist weitgehend wünschenswert, kann aber auch zu Problemen führen, wenn größere temporäre Datenstrukturen ungewollt mitgesichert werden (z.B. interne Buffer einer offenen Dateiverbindung). Einige Systeme offerieren eine Lösung durch die Möglichkeit der Überdefinition (oder Ergänzung) der System-Methoden zum Sichern und Einlesen von Objekten.

Persistenz auf Basis von Betriebssystemen:

Prozesse und Adreßräume unterliegen der Verwaltung durch ein Betriebssystem. Während bei konventionellen Betriebssystemen Prozesse und Daten beim Ende eines Prozesses oder spätestens beim Herunterfahren des Systems verlorengehen, gibt es einige verteilte Betriebssysteme, die auf Basis von virtuellen Speichertechniken erlauben, Objekte langfristig an bestimmten Adressen abzulegen. Damit entfällt die Notwendigkeit, die Objekte zu transferieren. Statt dessen findet jeder Prozeß, der die notwendigen Zugangsrechte hat, - unabhängig von seiner eigenen Lokalisierung - das Objekt an seiner festen Adresse (siehe beispielsweise das Monads-Projekt von Keedy). Diese Lösung ist sehr elegant und ermöglicht auch verteilte Systeme. Leider steht sie nur auf einigen wenigen experimentellen Betriebssystemen zur Verfügung.

Persistenz auf Basis systemunabhängiger Bibliotheken:

Wenn kein spezielles Betriebssystem zur Verfügung steht, die Programmiersprache nicht unnötig erweitert werden soll und die Unabhängigkeit von dem Programmiersystem wünschenswert ist, dann muß die Lösung in einer systemunabhängigen und damit portablen Bibliothek gesucht werden. Hierfür müssen zwar möglicherweise Performance-Einbußen hingenommen werden, jedoch sollte die dadurch gewinnbare Flexibilität darüber hinwegtrösten.