Deciding on the replication model

Typically, the backend database represents the master copy of the data and data must be cached in read-only mode. For such setups, only a single subscription is required. The backend datastore should be used as the subscription source and the cache data store (solidDB^®) should be used as the subscription target. This configuration ensures that any changes made to the backend can be replicated to the cache.

The following table shows the typical subscription configurations for Universal Cache. The Procedure column contains instructions on the type of subscriptions you should create in each case. The Procedure column also states the necessary conflict resolution option needed to prevent recursion.

Cache type	Behavior	Procedure
Backend owned, read-only cache	Changes made to backend database are reflected in cache (most typical scenario)	Create a single subscription using the backend datastore as source and the cache datastore as target.
Backend owned, read-write cache	Changes made to backend database are reflected in cache; changes made to cache are reflected in backend	Create a subscription using the backend data store as source and the cache data store as target. Specify SOURCE wins as conflict resolution option. Create another subscription using the cache data store as source and the backend data store as target. Specify TARGET wins as conflict resolution option.
Cache owned, archival	Changes made to cache are archived to backend.	Create a single subscription using the cache datastore as source and the backend datastore as target.
Cache owned, read-write cache	Changes made to backend database are reflected in cache; changes made to cache are reflected in backend.	Create a subscription using the cache datastore as source and the backend datastore as target. Specify SOURCE wins as conflict resolution option. Create another subscription using the backend data store as source and the cache data store as target. Specify TARGET wins as conflict resolution option.