Applications can be built to link with the shared memory access driver library or the linked library access library to use fully the in-memory database performance and responsiveness.

The SQL passthrough can be used to enable applications to access data both in the frontend and backend data servers with a single connection. For example, SQL passthrough can be enabled in such a way that those SQL statements that cannot be executed in the frontend are passed over to the backend.

For more details, see SQL passthrough.

The data aging feature enables applications to remove outdated data from the frontend database while preserving it in the backend. Data aging helps controlling main memory consumption in the frontend; some of the data in the frontend may become obsolete and it is not used by the applications. Removing the obsolete data frees frontend main memory resources.

For more details, see Data aging.

The fast refresh feature reduces the amount of time needed to replicate a large amount of data from the backend data server to the frontend. Most performance gains are achieved with simple setups; factors such as the amount of data per row per table, code page conversions, and column mappings will effect the performance of the fast refresh feature.

Fast refresh does not support the following IBM InfoSphere CDC functionality:

– Conflict detection

– Summarization

– Row consolidation

– Adaptive apply

– User exits

The solidDB^® High Availability features, including failovers in the solidDB^® server, are supported. For more information, see the solidDB^® High Availability User Guide.

If the replication cannot accommodate a sustained load in the solidDB^® server, the processing is throttled down (slowed). From the application standpoint, that results in increased response times. The replication traffic is buffered so that load bursts can be accommodated. The size of the corresponding in-memory buffer is controlled with the configuration parameter LogReader.MaxSpace.

If the replication is stopped, or it has failed, the solidDB^® server can continue to process the load, and accumulate the data for a later transfer. The limit of the accumulated data is set with the LogReader.MaxLogSize configuration parameter. When the amount of accumulated data exceeds the values of the LogReader.MaxLogSize parameter, the log overflow occurs, resulting in a situation where replication catchup is no longer possible. In that case, a refresh on the subscription is needed.

A number of runtime counters is available to monitor the operation of the solidDB^® capture (solidDB^® as a source) and apply (solidDB^® as a target) processes. See also the LOBS-related restriction in Restrictions on solidDB^® server in IBM InfoSphere CDC Replication deployments.

All solidDB^® data types are supported for replication.