The ObjectStore Component Server

The Component Server Framework includes the ObjectStore Component Server, which handles interaction between thin clients and ObjectStore components.

Each Component Server process supports a named service. A service is a collection of components, that is, shared libraries that act as plug-ins to the Server. Each component, in turn, supports one or more operations.

The Component Server supports high throughput and scalability by providing

Flexible transaction management: Servers can execute requests using a variety of transaction types. With most transaction types, the Server batches requests from different users into the same transaction, reducing commit overhead and increasing throughput.
Multiple-thread dispatching: Each Server handles requests using multiple threads, so requests share resources more efficiently and inexpensive requests do not have to wait for more costly ones.

Load balancing: To scale your application as the number of requests increases, you can configure Servers to use more threads. As the number of requests increases further, you can replicate Servers as many times as necessary for the required performance. One Server acts as router and distrubutes requests to Servers on a round-robin basis.

The Component Server is an ObjectStore client, that is, a client of ObjectStore database Servers.

You can start and stop ObjectStore Component Servers from the command line, or you can create a customized component server that manages start-up and shutdown of ObjectStore Component Servers.

Most applications use multiple Servers. Each Server is dedicated to a subset of the operations supported by a service. In many cases, the data set required by those operations can fit entirely, or almost entirely, into the Server's cache (which is an ObjectStore client cache).

When you start or configure a Server, you specify the following parameters, which are related to routing client requests to the appropriate Server:

Transaction type: Each Server runs a specific type of transaction, isolated_update, shared_update, read, or mvccRead. Each operation is implemented to use one of these transaction types. Requests for execution of given operation are routed to a Server running that operation's type of transaction.
Optional routing data: This is a pointer to any user-specified data, such as a character string. A thin client can specify routing data along with the request, and the request is routed to a Server with matching routing data.

Because clients can specify routing data on a per-operation basis, clients can route requests based on operation arguments. For example, an application that operates on bank accounts can route operations based on account number. That way, different Servers can be dedicated to the data for different ranges of account numbers. This allows you to scale the application by adding more Servers as the number of accounts increases, and keep the application operating almost entirely on hot caches.

You can manually warm up each cache when you initialize the application, or you can let thin client requests populate the caches incrementally. In the latter case, because of ObjectStore's Cache-Forward architecture, each cache is automatically populated with the desired data set by virtue of the routing that takes place. In both cases, ObjectStore automatically maintains the validity of all Component Server caches.

Using multiple Servers can also increase the fault tolerance of your application. By replicating Servers, including router Servers, you can easily avoid single-point-of-failure vulnerability. In addition, routers maintain route data persistently, which also increases applications' fault tolerance.

[previous] [next]