UltraLiteJ supports databases in memory (non-persistent) and in device storage (persistent). For Java SE, the file system is device storage. For BlackBerry smartphones, it is the BlackBerry object store.
Transactions are the set of operations between commits or rollbacks. For persistent database stores, a commit makes permanent any changes since the last commit or rollback. A rollback returns the database to the state it was in when the last commit was invoked.
Each transaction and row-level operation in UltraLiteJ is atomic. An insert involving multiple columns either inserts data to all the columns or to none of the columns.
UltraLiteJ provides both automatic and manual checkpoint capabilities. When set to automatic, commit statements cause table rows and indexes to be updated; otherwise, checkpoints are invoked using the checkpoint method of the Connection interface.
UltraLiteJ uses isolation level zero (read uncommitted) to provide the maximum level of concurrency.
Locking Two different connections cannot modify the same row at the same time. If two connections attempt to operate on the same row, one connection is blocked until the other connection finishes.
Visibility One connection's operation on the database is immediately visible to other connections.
Persistent stores are page based; UltraLiteJ operates on pages in cache. A working set of pages is maintained in cache and is managed using a first-in, first-out (FIFO) scheme. Pages that are currently in use are locked in cache to avoid being swapped out.
You can configure the size of the UltraLiteJ cache.
UltraLiteJ can use lazy load indexes and row pages to improve the startup of a persistent database. Indexes and row pages are only loaded when first accessed by an application.
Encryption is set using the setEncryption method of a Configuration object, which takes an EncryptionControl to encrypt and decrypt pages. You must supply your own encryption control.
As a MobiLink synchronization client, UltraLiteJ has a built-in transaction log-based change tracking system so that database changes can be synchronized.
Data synchronization can be performed using HTTP or HTTPS network protocols. HTTPS synchronization provides secure encryption to the MobiLink server.
To make more efficient use of network resources, UltraLiteJ provides a publication model that lets you synchronize selected tables from your database.
UltraLiteJ uses Unicode (encoded as UTF-8 in the database). The collation is the default sort order for Java and is equivalent to the UTF8BIN collation supported by SQL Anywhere. During synchronization with a MobiLink server, UltraLiteJ notifies MobiLink that it uses the UTF8 character set and collation.
| Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |