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 |
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.
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.
| Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |