Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Français) » UltraLiteJ » Using UltraLiteJ » Introduction to UltraLiteJ

 

UltraLiteJ database stores

Supported database stores

The following is a list of database store types supported by UltraLiteJ:

Database store type Platform support
File system store Java SE
RIM object store (RIM11) Java ME
Record store Java ME
Non-persistent store All Java platforms
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 an object handle to store a value in the database. For example, a table row with ten columns and two indexes requires a minimum of twelve object handles.

To permit a larger database store, UltraLiteJ requires a 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.

  • 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.

  • Shadow paging persistence   Shadow paging is the strongest form of persistence. It can be enabled using the setShadowPaging method of a persistent configuration object. When enabled on startup, it provides database recovery to the state at the last checkpoint, even if the application terminates unexpectedly.

  • 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.