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 |
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.
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.
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.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |