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

SQL Anywhere 11.0.0 » UltraLiteJ » Using UltraLiteJ » Introduction to UltraLiteJ


UltraLiteJ features

Database store

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 of the columns or to none of the columns.

Checkpoint and recovery

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.

Concurrency and locking

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.

Cache management

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.

Built-in change tracking

As a MobiLink synchronization client, UltraLiteJ has a built-in transaction log-based change tracking system so that database changes can be synchronized.

HTTP and HTTPS communication

Data synchronization can be performed using HTTP or HTTPS network protocols. HTTPS synchronization provides secure encryption to the MobiLink server.

Synchronization publications

To make more efficient use of network resources, UltraLiteJ provides a publication model that lets you synchronize selected tables from your database.

Character sets and collations

UltraLiteJ uses Unicode (encoded as UTF-8 in the database). The collation is Java's default sort order (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.