Datenpersistenz bei Java-Applikationen

Sind die Updates oder ist das Persistieren neuer Objekte fertig, müssen die Änderungen mit der commit-Methode des RecordManager, welche die JDBM-Transaktion abschließt, übergeben werden. Man kann auch die rollback-Methode verwenden, um Änderungen bis zur letzten Übergabe aufzuheben, doch diese Methode beherbergt Fallstricke. Hier der Rest von generateTaskId, das die gespeicherte Task-ID aktualisiert:


Nun könnte genau dieser Teil der JDBM-API verwendet werden, um viel Persistenz zu managen, doch es gibt zwei Klassen, die auch verwendet werden können und welche die JDBM viel praktischer machen, und zwar HTree und BTree. Mit HTree erhält JDBM einen einfachen, persistenten Hash-Tree, in den man über put() mit Schlüsseln versehene Werte einfügen und mit get() aufrufen kann. Doch fehlen ihm eine Semantik für das Ordnen und die Größen. Der BTree ist ein besser skalierbarer und managebarer Baum mit Semantik zum Ordnen und für die Größen und der Fähigkeit, den Baum zu durchsuchen. Der BTree wird in der Tasks-Klasse verwendet, um die Task-Instanzen zu speichern. Um einen BTree zu erzeugen, wird eine statische Methode, createInstance, in BTree aufgerufen, durch die er einen Record-Manager und eine Comparator-Instanz erhält, mit der Schlüssel verglichen werden können. JDBM verfügt über einen Satz von Comparators für Long, String und ByteArray; da in diesem Fall der Schlüssel ein Long ist, wird der LongComparator verwendet:


Nun ist eine BTree-Instanz vorhanden, und man kann die setNamedObject()-Methode verwenden, um einen Verweis auf den Record zu sichern; der BTree behält einen Verweis auf seine eigene Record-ID im JDBM-Store, die man mit der getRecid()-Methode erhält.


Um einen vorhandenen BTree aufzurufen, kann man ihn nun mit der getNamedObject() suchen. Um jedoch die BTree-Instanz neu zu erzeugen, verwendet man die statische load()-Methode von BTree. Load() nimmt den Record-Manager und die Record-ID als Parameter und gibt eine BTree-Instanz zurück.


Die Arbeit mit dem BTree ist leicht; man kann seine insert-Methode verwenden, um Datensätze hinzuzufügen:


Der boolsche Parameter am Ende gibt an, ob das insert den Datensatz ersetzen soll, wenn der Schlüssel schon vorhanden ist. In diesem Fall wird ein neuer Datensatz eingefügt, daher ist er auf false gesetzt. Die insert()-Methode gibt tatsächlich ein Objekt zurück, das der Wert des vorhandenen Schlüssels wäre. Um den Wert eines Schlüssels zu erhalten, verwendet man die find()-Methode; in JDBMTaskImpl.java gibt es:


Um sich im Baum bewegen zu können, gibt es den TupleBrowser. Man bekommt ihn vom BTree, indem die browse()-Methode verwendet wird, die einen TupleBrowser zurückgibt, der am Anfang des Schlüssels des Baums positioniert ist. Wenn man browse() einen Schlüssel übergibt, wird der TupleBrowser gleich vor diesem Schlüssel im Baum positioniert, und wenn eine Null als Schlüssel übergeben wird, positioniert er sich am Ende; in JDBMTasksImpl.java verwendet man dies in getTaskIds(), das eine Aufstellung aller Schlüssel der Reihe nach zurückgeben muss, daher wird vom Anfang aus durchsucht;


Sobald der TupleBrowser zur Verfügung steht, muss ein Tupel erzeugt werden, um Schlüssel/Wert-Paare zu halten:


Der TupleBrowser übernimmt diesen Tupel als Parameter, wenn die getNext()- oder die getPrevious()-Methode des TupleBrowsers aufgerufen wird. Beide Methoden geben einen boolschen Wert zurück, true, wenn ein Tupel gefunden wurde, false, wenn nicht. Um dies für alle Schlüssel/Wert-Paare durchzuführen, kann getNext() aufgerufen werden, bis es false zurückgibt:


Mit dem TupleBrowser ist es bequem sich im Baum zu bewegen. Wenn jedoch strukturelle Änderungen am Baum vorgenommen werden, wird der TupleBrowser inkonsistent und man sollte eine neue Instanz erzeugen. Wie weiter oben bemerkt, gibt es einen Trick bei der Verwendung von BTree und HTrees und JDBM-Rollback, den nämlich, dass Rollback BTrees und HTrees im Speicher für ungültig erklärt. Wenn man also ein Rollback vornimmt, muss man sämtliche Bauminstanzen neu laden.

Mit JDBM steht eine einfache und schlanke Persistenz-Schicht für ToDoTasks zur Verfügung; die gesamte JDBM-Bibliothek jdbm.jar ist eine jar-Datei von 88 KByte, die man auf der JDBM-Website findet.

Themenseiten: Anwendungsentwicklung, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Datenpersistenz bei Java-Applikationen

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *