UltraLiteJ database stores

Supported database stores

The following is a list of database configurations supported by UltraLiteJ:

Database store type	Configuration	Platform
File system	ConfigFile	Java SE
RIM object store	ConfigObjectStore	BlackBerry
Record store	ConfigRecordStore	Java ME
BlackBerry file system	ConfigFileME	BlackBerry

BlackBerry object store limitations

On a BlackBerry smartphone, the size of the database store is limited by the number of object handles available. The number of available object handles is determined by the size of the flash memory:

Flash memory	Persistent handles	Handles
8 MB	12000	24000
16 MB	27000	56000
32 MB	65000	132000

UltraLiteJ requires one or more object handles, depending on the handle type, to store a database value in memory. For example, a table row with ten columns and two indexes requires a minimum of twelve object handles.

To permit larger database stores, UltraLiteJ allows users to limit the number of rows kept in memory. Stored database rows are combined on a database page. UltraLiteJ requires only one persistent object handle for each database page.

Persistent store configurations and recovery

When creating your database, use the Configuration object to choose one of the following forms of persistence for your application.

Non-persistence Creating a NonPersist object configures a database store that only exists in memory. The database is created at startup, used while the application is running, then discarded when the application closes. When the application closes, all data contained in the non-persistent store is deleted.
Shadow paging persistence Shadow paging is the strongest form of persistence. It can be enabled using the setShadowPaging method of a persistent configuration object. If it is enabled when the database is created, it provides database recovery to the state at the last commit or rollback, even if the application terminates unexpectedly.
Write-at-end persistence When write-at-end persistence is enabled using the setWriteAtEnd method of a persistent configuration object, data is only written to the database when the connection is released. While this form of persistence improves the overall speed of transactions, data could be lost if the application terminates abnormally.
Simple paging persistence When shadow paging is not enabled, a simple paging implementation of persistence is used. All data is written to the same page from which data is read. The database is considered corrupt from the time updating starts to the time before updating completes. A corrupt database can be detected during startup, but it is not recoverable. In comparison to shadow paging, simple paging uses significantly less memory and improves performance.

Note

Write-at-end and simple paging persistence should only be used in applications when the loss of data can be tolerated, the database can be easily recreated, or the database is not updated.

Discuss this page in DocCommentXchange.