Persistenz ist in ONTOS weder orthogonal noch unabhängig. Das Aktivieren und Deaktivieren eines Objekts liegt in Verantwortung des Programmierers. Daneben sind auch nur die Unterklassen von Object persistent. Beim Aktivieren eines Objektes kann man wählen, ob nur dieses einzelne Objekt, der gesamte Cluster dieses Objekts oder alle von diesem Objekt über die Klasse-Komponentenklasse-Beziehung erreichbaren Objekte aktiviert werden sollen.
Auch die Strategie der Pufferverwaltung ist von außen zu beeinflussen: So kann gewählt werden, ob eine Deaktivierung das Objekt vom Client sofort zum Server weitersendet, ob dies erst bei einer bestimmten Anzahl von deaktivierten Objekten (etwa zehn) geschieht oder ob gewartet wird, bis ein Commit die Übertragung explizit fordert.
Neben den Cluster-Strukturen unterstützt ONTOS noch verschiedene
Zugriffspfade bei den neu eingeführten Aggregate-Klassen.
Mengen werden hier mit einem linearen Hashverfahren
als Speicherstruktur repräsentiert. Die Dateiorganisation eines Dictionaries
kann auf linearem Hashing (falls die Elemente des Dictionaries ungeordnet sind)
oder auf B-Bäumen (im geordneten Fall) basieren.
ONTOS bietet geschachtelte Transaktionen an. Aktiviert man Objekte auf unterschiedliche Weise (einzeln, im Cluster, alle Komponentenobjekte), so werden auch unterschiedliche Sperren gesetzt. Treten Konflikte beim Zugriff verschiedener Benutzer auf die gleichen Objekte auf, so können durch Angabe von Ausnahmebehandlungen diese Konflikte aufgelöst werden. ONTOS stellt dazu C++-Klassen zur Verfügung, die Ausnahmebedingungen und Ausnahmebehandlungen aufnehmen können.
Zur Transaktionssteuerung gibt es die Standard-Methoden TransactionStart,
TransactionCommit und TransactionAbort. TransactionStart
kann noch mit etlichen Parametern versorgt werden, etwa um die
Art der Pufferung und die Art der Konfliktauflösung innerhalb dieser
Transaktion festzulegen.