Wie entwickelt man Klassen für persistente Daten in Terrakotta?

Question

Wir erwägen Terrakotta für unser nächstes Projekt.Ich bin fasziniert von seinem Potenzial, Datenpersistenz ohne die Notwendigkeit eines separaten DBMS bereitzustellen.(Siehe auch Über die Verwendung von Terrakotta als Persistenzlösung)

Eine der Hauptschwierigkeiten der Softwareentwicklung besteht darin, die vorhandenen Produktionsdaten an das neue Datenmodell anzupassen.Für ein RDBMS würden Sie wahrscheinlich zum Zeitpunkt der Bereitstellung ein SQL-Änderungsskript verwenden.Bei Terrakotta-gestützten Daten ist mir nicht sofort klar, wie ich mit nicht-trivialer Evolution umgehen soll.

Es gibt eine einige Absätze zur Klassenentwicklung in der Terrakotta-Dokumentation aber es scheint spezifisch für DSO und bleibt eher oberflächlich.

1. Welche Möglichkeiten gibt es, um die Datenmodellentwicklung für die in Terrakotta gespeicherten persistenten Daten zu handhaben? Ich interessiere mich besonders für das Nicht-DSO-Szenario (d. h.über die Terrakotta-Toolkit-API).
2. Unterscheiden sich Terrakotta-DSO und die Toolkit-API in ihren Reaktionen auf weiterentwickelte Klassendefinitionen?
3. Um die Grenzen der Klassenentwicklung zu verstehen, wäre es hilfreich zu wissen, wie Terrakotta Objektdaten darstellt / kommuniziert;gibt es dafür eine Spezifikation?
4. Vielleicht gibt es Schemaentwicklungstechniken aus der OODBMS-Welt, die auf Terrakotta anwendbar sind?

Nehmen wir als triviales Beispiel an, ich habe eine Menge Car objekte gespeichert und ich habe die geändert modelYear bereich der Car klasse von a String zu einem int.Laut Dokumentation funktioniert dies nicht sofort.Ich kann mir eine Lösung vorstellen, bei der mein alter Car wird beim Start der Anwendung von einem separaten Klassenlader geladen und dann in einen neuen konvertiert Car.Wäre das ein guter Ansatz und warum (nicht)?

Answer 1

Es hängt von Ihrem Anwendungsfall ab.

Wenn die Kosten für das Laden Ihres Caches minimal sind (Minuten) und Sie sich Ausfallzeiten leisten können...dann sehe ich kein Problem darin, einfach Ihren Cache für eine neue Version neu zu erstellen.

Wenn Sie hohe Kosten für das Auffüllen Ihres Caches haben (Stunden / Tage) und sich keine großen Ausfallzeiten leisten können, müssen Sie während der Übergangszeit gleichzeitig mit der neuen und der alten Version umgehen.Dafür:

1. Ich würde eine separate Cache-Definition für jede neue Version von definieren die zwischengespeicherte Klasse und lassen Sie die alte Version im Cache ablaufen.
2. Anwendungscode sollte auch "alte / neue Version" unterstützen.
3. Haben Sie eine Instanz, die bis zu den Daten noch mit der alten Version funktioniert läuft ab / veraltet (basierend auf einem alten Cache-Namen)
4. Habe eine Instanz, die alle neuen Anfragen / Flows mit einem neuen bearbeitet version (basierend auf einem neuen Cache-Namen)

beispielsweise.im ehcache.xml würden Sie 2 Caches definieren (basierend auf Ihrem Beispiel):

<cache name="com.xyz.Car" timeToLiveSeconds="600"/>
<!--New version goes here-->
<cache name="com.xyz.Car2" timeToLiveSeconds="600"/>

Auf lange Sicht sollten Sie die Namenskonvention für Ihre Caches trainieren, die die Versionsentwicklung einschließt.