Datenpersistenz bei Java-Applikationen

Manchmal braucht man für eine Applikation nur eine einfache, verwaltbare Art und Weise, Objekte zu persistieren; dann ist sogar eine eingebettete SQL-Datenbank wie HSQLDB oder Derby/JavaDB einfach zu viel. Genau für diese Situationen gibt es JDBM. Mit JDBM in der einfachsten Form kann man Objekte mit einem „long“-Wert für eine Record-ID speichern. Es gibt keine Datenbank-Abfragen, bloß eine einfache find-Methode, um ein Objekt anhand seiner Record-ID aufzurufen. Natürlich ist es nicht einfach, nur mit diesen Record-IDs zu arbeiten. So gibt es zum Beispiel die Frage, woher eine Applikation beim Start weiß, welche Record-IDs welche Daten repräsentieren. Um das zu umgehen, bietet JDBM die Möglichkeit, Objekte mit Namen zu erzeugen, wobei der Name auf eine Record-ID gemappt wird. So kann man nachschauen und die Record-IDs für „wichtige“ Objekte aus dem JDBM-Store holen.

Die JDBM-Implementation von ToDoTasks befindet sich in JDBMTasksImpl.java. Um JDBM verwenden zu können, muss ein JDBM-RecordManager erzeugt werden, den man von der RecordManagerFactory erhält und die ihm einen Dateinamen als Parameter übergibt, der als Basisname für die zwei Dateien dient, die JDBM erzeugt:

Will man ein neues Objekt speichern, muss die insert-Methode des RecordManager aufgerufen werden, der die Record-ID, die man zum Wiederaufrufen des gespeicherten Objekts braucht, ausgibt. Dieser Datensatz bekommt einen Namen, indem man die setNamedObject-Methode des RecordManager mit einem Namen und der Record-ID, die mit diesem Namen verbunden werden soll, aufruft. Die speichert zum Beispiel aus der generateTaskId-Method von Tasks:

einen Long und erzeugt einen Namen, „nextid“, der mit der Record-ID verbunden ist, den das Insert ausgibt. Will man ein Objekt aus dem Store wieder aufrufen und kennt die Record-ID, so ruft die fetch-Methode des RecordManager es auf:

Ist die Record-ID nicht zur Hand und handelt es sich um ein Objekt, das einen Namen erhalten hat, kann die Record-ID mithilfe von getNamedObject des RecordManager in Erfahrung gebracht werden. Es wird entweder die Record-ID ausgeben oder 0, falls das benannte Objekt nicht existiert. Man kann das Attribut verwenden, um zu bestimmen, ob der Store zu initialisieren ist. In generateTaskId von Tasks gibt es ein Beispiel dafür:

Einen Datensatz aktualisiert man durch einen Aufruf der update-Methode des RecordManager, die die Record-ID und ein Objekt nimmt und mit diesem Objekt ersetzt, was auch immer sich an der Stelle befindet. Es ist möglich eine völlig andere Klasse in der Aktualisierung unterzubringen, ohne dass sich JDBM beschwert, denn es betrachtet die Dinge lediglich als serialisierbare Objekte. Das ist gut, wenn man Klassen mit einer gemeinsamen Subklasse oder Schnittstelle persistiert, kann aber zu ClassCastExceptions führen, wenn man es nicht sorgfältig managt.