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
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 uses isolation level zero (read uncommitted) to provide the maximum level of concurrency.
Two different connections cannot modify the same row at the same time. If two connections attempt to operate on the
same row, the second connection receives an error and becomes prohibited from modifying the row until the first connection
commits or rolls back its current transaction.
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
You can configure the size of the UltraLiteJ cache.
UltraLiteJ can use the lazy loading of 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.
For small databases, UltraLiteJ keeps copies of all row and index pages in memory.
For larger databases, the database can be configured each time it is opened to limit the number of rows and index pages that
resident in memory at one time.
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.