When configured as a read-write cache where the data ownership is shared, applications can update the same data in both the cache and in the back-end database at the same time. In this case, changes to the data can be propagated automatically in both directions. Conflicts are detected and resolved by using predefined conflict resolution methods. This configuration is especially useful when applications need to update the data in the back-end database while the data is also cached for read-write access.

3.3 Configuration alternatives

This section describes the configuration alternatives for the deployment options.

3.3.1 Typical configuration

A simple solidDB Universal Cache deployment might involve caching a single back-end database to a single cache database. The cache database related components and the back-end related components are installed on separated nodes, as are the Access Server and tooling. A typical node configuration is shown in Figure 3-4.

Figure 3-4 A simple solidDB Universal Cache deployment with a single cache node

46 IBM solidDB: Delivering Data with Extreme Speed

Note the following information:

Single cache node

The solidDB server and InfoSphere CDC for solidDB products are typically installed and configured on the same machine (“cache node”). This machine is often “closer” to the applications that use the data.

Collocation of the two servers minimizes the overhead when scraping the logs (solidDB as source) or applying updates (solidDB as target).

Single database node

The InfoSphere CDC for back end is typically installed and configured on the same machine on which the back-end RDBMS is running (“database node”).

This approach helps to minimize the overhead of communications between the replication engine and the database.

Single access node

The Access Server is typically deployed on a separate machine (“access node”). The advantage to installing it on a separate machine from “cache” and “database” nodes is to more easily configure the firewall, because solidDB Universal Cache tooling communicates with the Access Server, not with the InfoSphere CDC replication engines.

InfoSphere CDC Access Server is only required during the configuration of solidDB Universal Cache, or during the starting or stopping of caching (that is, subscriptions).

Configuration nodes

Any node from which solidDB Universal Cache tooling (Management Console, dmsubscriptionmanager, Access Server tools) is run can be considered a configuration node.

3.3.2Multiple cache nodes

Multiple solidDB servers (cache nodes) can be used, for example, for partitioning back-end data so that each cache node has only the data that is relevant to it. However, in such deployments, each solidDB server is autonomous and processes the application requests without accessing data in any of the other solidDB servers.

3.3.3 SMA for collocation of data

The shared memory access (SMA) feature of solidDB Universal Cache can boost application performance when accessing solidDB data. In place of costly network-based communication, such as TCP/IP, SMA uses direct function calls

Chapter 3. IBM solidDB Universal Cache details 47

to the solidDB server code. In the same time, the in-memory database is located in a shared memory segment available to all applications connected to the server with SMA. Multiple concurrent applications running in separate processes can utilize that access method to reduce significantly response times.

In a SMA setup, the application, the solidDB SMA server, and the InfoSphere CDC replication engine are located on the same node. In the setup phase, the following steps must be considered:

1.Configuring solidDB server to run as a SMA server

2.Configuring InfoSphere CDC for solidDB to use SMA for communication with solidDB server

3.(Optional) Configuring user applications to use SMA for communication with solidDB server

Configuring solidDB server to run as a SMA server

To use solidDB with SMA, the solidDB server is started with the solidsma executable, instead of the solid executable.

Configuring InfoSphere CDC to support SMA

SMA must be enabled during the creation of an InfoSphere CDC for solidDB instance. For example, in the GUI tool, the Enable SMA check box must be selected; see Figure 3-5.

Figure 3-5 Enabling SMA on an InfoSphere CDC for solidDB instance

48 IBM solidDB: Delivering Data with Extreme Speed

Configuring user application to support SMA

The SMA feature does not require any code changes to the applications themselves, except for ensuring that the solidDB connection is configured for SMA. The SMA connection is defined within the ODBC connection string or JDBC connection property. For example, when using ODBC, instead of connecting to solidDB using the connection string ‘tcp 2315’, the SMA connection is specified with the string ‘sma tcp 2315’ string. When using JDBC, the following connection property is used:

solid_shared_memory=yes

3.3.4 solidDB HSB servers for high availability

The solidDB HotStandby (HSB) solution allows for redundancy to be incorporated at each individual cache node, thus providing reliable access to data stored in the cache database.

Reliability in the cache database requires that the data pathways to and from the cache are capable of handling HSB failovers. The InfoSphere CDC for solidDB can be made aware of HSB deployments transparently, so that replication to and from the cache remains operational, after the primary solidDB server is down. If the primary solidDB server does go down, InfoSphere CDC simply redirects active subscriptions to use the new primary solidDB server and replication continues as normal.

The HSB support must be enabled explicitly when configuring the InfoSphere CDC for solidDB instance by defining the connection to the primary and secondary servers, as shown in Figure 3-6.

Figure 3-6 Enabling HotStandby in InfoSphere CDC for solidDB

Chapter 3. IBM solidDB Universal Cache details 49