Resolving the Master-Slave Delay Problem

The LDAP data cache resolves the master/slave LDAP configuration problem by providing Calendar Server clients with the most recent LDAP data, even when the master directory server has not updated each slave directory server.

If the LDAP data cache is enabled, Calendar Server writes committed LDAP data to the cache database (ldapcache.db file). By default, the LDAP cache database is located in the /var/opt/SUNWics5/csdb/ldap_cache directory, but you can configure a different location if you prefer.

When a client makes a change to the LDAP data for a single user, Calendar Server writes the revised data to the LDAP cache database (as well as to the slave directory server). A subsequent client operation retrieves the LDAP data from the cache database. This data retrieval applies to the following operations for a single user:

• User’s attributes at login

• User’s options (such as color scheme or time zone)

• User’s calendar groups

• User’s subscribed list of calendars

Thus, the LDAP data cache database provides for:

• Data consistency across processes on a single system—The database is available to all Calendar Server processes on a multiprocessor system.

• Data persistence across user sessions—The database is permanent and does not require refreshing. You can configure the time to live (TTL) for an LDAP data cache entry and the interval between each database cleanup.

Limitations to the LDAP Data Cache Solution

The LDAP data cache does not provide for:

• Reading the cache for searches where a list of entries is expected, for example, searching for attendees for a meeting. This type of search is subject to any LDAP delay. For instance, a newly created calendar will not appear in a calendar search if the LDAP search option is active and the search is performed within the delay period following the creation of a new calendar.

• Reading and writing of the cache across multiple front-end servers. Each front-end server has its own cache, which is not aware of data in other caches.

• The capability to handle a user who doesn’t always log into the same server. Since each server has its own LDAP cache, within the delay period, one cache will not know about the user's activities while logged into the another cache.