COM In-Memory Database (IMDB)

A new feature in COM+ is the In-Memory Database (IMDB), a database that maintains its tables in memory. There are several reasons why having such a database might be useful.

Many applications need to retrieve fairly static data from persistent tables. For example, an application might use a table of valid ZIP codes and the corresponding city, state, and area code to automatically fill in the city and state fields of a data entry form when the user enters a ZIP code. A business object might use the table to validate the phone number for a given address. This table will be large, and retrieving it from a persistent database over and over again will lead to performance problems. By using IMDB as a cache for the persistent database, the table can be loaded once from the persistent database into an IMDB database. Data objects would be configured to retrieve information from the IMDB database rather than the persistent database. Because memory is relatively cheap, this approach can be an inexpensive way to improve the performance of developers' applications.

While caching is primarily useful for read-only data, it can also be used for read/write scenarios. This technique can be useful when an application's data objects reside on a different computer than the database server. To reduce the network traffic involved in reading and writing the database, an IMDB cache can be configured on the data object server computer. Data objects can read and write to the IMDB. Updated records are propagated back to the persistent store when transactions commit. This approach works particularly well when the database can be partitioned such that only one computer is updating a particular subset of records through the cache.

IMDB also offers a powerful alternative to the Shared Property Manager (SPM) for managing shared transient state. Unlike the SPM, IMDB can be used to share information across server processes. Because IMDB is an OLE DB provider, ADO can be used to access information stored in an IMDB database. Developers are more likely to be familiar with the ADO interfaces than the SPM interfaces, making it easier to implement shared transient state.

Figure 9.9 shows how IMDB works. The COM Explorer is used to configure the IMDB server process to run on a particular computer. This process runs as a Windows NT service. The IMDB server process is responsible for managing IMDB tables and interacting with any underlying persistent databases. The database tables are kept in shared memory; the COM Explorer can be used to configure how much memory is set aside for these tables. IMDB also provides a proxy, which is an OLE DB provider that runs in each client process. The proxy can interact directly with the IMDB tables for read-only scenarios, but it must go through the server process for read/write scenarios or to request locks on the data.

Figure 9.9 Accessing the COM+ IMDB

CAUTION

---

In COM+ 1.0, IMDB is limited to a single computer. If information is cached from a persistent database to an IMDB database running on multiple computers, there is no coordination across computers. Likewise, transient state managed by an IMDB database is local to a computer. However, future versions of IMDB are expected to include a distributed cache coordinator and a lock manager, to enable coordination across computers.

IMDB imposes some restrictions on the types of database tables it supports. In particular, the tables must have primary keys, and all changes to the tables must be performed by the IMDB. This means that some database features such as auto-increment fields, time-stamp fields, and triggers cannot be used in an IMDB database. In addition, IMDB does not provide a query processor and does not permit tables to be partially loaded from a persistent store; instead, the entire table must be loaded. The table can be sorted and filtered using ADO Recordset objects.

Despite these restrictions, using IMDB from components is straightforward. Developers can use either OLE DB or ADO to access IMDB tables. To do so, developers provide a DSN to establish the database connection and then use normal OLE DB or ADO methods. The DSN is configured using the COM Explorer. Developers also use the COM Explorer to map the IMDB data source to a persistent data source and to define which tables, if any, are loaded from the persistent data source when the IMDB server process starts.