1.0

Table Of Contents
Chapter 30
SQLFire Cache Strategies
You can deploy SQLFire as a distributed cache for data that is managed in a traditional relational database system.
SQLFire offers several strategies for using the product as a database cache.
Considerations for Auto-Generated Keys on page 173
Lazy-Loading the Cache on page 173
Preloading Strategies on page 173
Integration with Hibernate on page 174
Exporting and Transforming an Existing Schema on page 174
Considerations for Auto-Generated Keys
If cached tables require automatic generation of identity column values, then you should use SQLFire to automatically
generate the key values but disable generated keys in the backend database. If the backend database also generates key
values, then inserts can fail if SQLFire has already generated the key.
Note: SQLFire supports automatic generation of identity column values, but it does not support generating a
sequence of key values. If a sequence is required, then consider using a stored procedure to obtain the next
sequence value from the backend database before inserting the row in SQLFire.
Lazy-Loading the Cache
Application query requests are rst attempted in SQLFire. On a miss, a loader that implements lazy loading is invoked
that can fetch the data from a backend database. SQLFire only supports primary key-based queries when the table is
lazily loaded. It is impractical (too expensive) to determine the subset of the rows missing in SQLFire and construct
a query to the backend database that only fetches the missing rows. It is also typical for applications to congure
least-recently-used (LRU) caching where the cache optimizes the available memory by evicting the least frequently
used rows. Applications can only issue primary key-based queries on tables that are congured for eviction. For more
information, see Using a RowLoader to Load Existing Data on page 175.
All updates can be synchronously or asynchronously written back to the database using a 'writer' or the built in Using
DBSynchronizer to Apply DML to an RDBMS on page 191. For tables that are identical in structure to the backend
database, applications can asynchronously "write behind" if you congure the database URL for the backend database.
Preloading Strategies
SQLFire offers several caching strategies that involve preloading data.
Preload database. Load the entire database at bootstrap time into SQLFire. If all updates are going through SQLFire,
it is unnecessary to resynchronize the state from the backend database. The data bootstrapping process is outlined
below. With this choice, the tables are loaded with the entire data set from the backend database and all queries can
directly be executed on SQLFire data stores.
173