UltraLiteJ-Datenbankspeicher

Unterstützte Datenbankspeicher

Im Folgenden finden Sie eine Liste der Datenbankkonfigurationen, die von UltraLiteJ unterstützt werden:

Typ des Datenbankspeichers	Konfiguration	Plattform
Dateisystem	ConfigFile	Java SE
RIM-Objektspeicher	ConfigObjectStore	BlackBerry
Record-Store	ConfigRecordStore	Java ME
BlackBerry-Dateisystem	ConfigFileME	BlackBerry

Einschränkungen des BlackBerry-Objektspeichers

Bei einem BlackBerry-Smartphone wird die Größe des Datenbankspeichers durch die Anzahl der verfügbaren Objekt-Handles eingeschränkt. Die Anzahl der verfügbaren Objekt-Handles wird durch die Größe des Flash-Speichers bestimmt:

Flash-Speicher	Beständige Handles	Handles
8 MB	12000	24000
16 MB	27000	56000
32 MB	65000	132000

UltraLiteJ erfordert einen oder mehrere Objekt-Handles, abhängig vom Handle-Typ, um einen Datenbankwert im Speicher abzulegen. Eine Tabellenzeile mit zehn Spalten und zwei Indizes erfordert beispielsweise ein Minimum von zwölf Objekt-Handles.

Um größere Datenbankspeicher zu ermöglichen, gibt UltraLiteJ Benutzern die Möglichkeit, die Anzahl der im Speicher aufbewahrten Zeilen zu begrenzen. Gespeicherte Datenbankzeilen werden auf einer Datenbankseite kombiniert. UltraLiteJ erfordert nur einen beständigen Objekt-Handle für jede Datenbankseite.

Konfigurationen des beständigen Speichers und Wiederherstellung

Wenn Sie Ihre Datenbank erstellen, verwenden Sie das Configuration-Objekt, um eine der folgenden Formen von Beständigkeit für Ihre Anwendung auszuwählen.

Keine Beständigkeit Das Erstellen eines NonPersist-Objekts konfiguriert einen Datenbankspeicher, der nur im Arbeitsspeicher existiert. Die Datenbank wird beim Starten erstellt und während der Ausführung der Anwendung verwendet, um dann beim Schließen der Anwendung verworfen zu werden. Wenn die Anwendung geschlossen wird, werden alle im nicht-beständigen Speicher enthaltenen Daten gelöscht.
Shadow Paging-Beständigkeit Shadow Paging ist die stärkste Beständigkeitsform. Sie kann aktiviert werden, indem die setShadowPaging-Methode eines beständigen Configuration-Objekts verwendet wird. Wenn dies während der Erstellung der Datenbank aktiviert ist, kann die Datenbank auf den Status beim letzten Festschreiben oder Zurücksetzen wiederhergestellt werden, auch wenn die Anwendung unerwartet beendet wird.
Write-at-end-Beständigkeit Wenn die Write-at-end-Beständigkeit unter Verwendung der setWriteAtEnd-Methode eines beständigen Configuration-Objekts aktiviert ist, werden Daten erst in die Datenbank geschrieben, wenn die Verbindung freigegeben wird. Während diese Form der Beständigkeit die allgemeine Geschwindigkeit von Transaktionen verbessert, können Daten doch verloren gehen, falls die Anwendung abnormal beendet wird.
Einfache Paging-Beständigkeit Wenn Shadow Paging nicht aktiviert ist, wird eine einfache Paging-Implementierung von Beständigkeit verwendet. Alle Daten werden auf die Seite geschrieben, von der Daten gelesen werden. Die Datenbank wird vom Zeitpunkt des Beginns der Aktualisierung bis zum Zeitpunkt vor dem Abschluss der Aktualisierung als beschädigt angesehen. Eine beschädigte Datenbank kann beim Starten erkannt werden, ist aber nicht wiederherstellbar. Im Vergleich zu Shadow Paging verwendet einfaches Paging signifikant weniger Speicher und verbessert die Performance.

Hinweis

Write-at-End-Beständigkeit und einfache Paging-Beständigkeit sollten nur in Anwendungen verwendet werden, bei denen der Verlust von Daten tolerabel ist, die Datenbank auf einfache Art neu erstellt werden kann oder die Datenbank nicht aktualisiert wird.

Kommentieren Sie diese Seite in DocCommentXchange.