Sun Java Communications Suite 5 Deployment Planning Guide

Planning for the Calendar Server LDAP Data Cache

The LDAP data cache option ensures that LDAP data is available immediately after it has been committed. In some configurations of LDAP, an update might need to be referred to a (remote) master server from which the update is then replicated down to the local LDAP directory. These kinds of configurations can induce a delay in the availability of committed data on the local LDAP server.

The LDAP data cache can ensure that your Calendar Server clients have accurate LDAP data, but can introduce a delay in the availability of committed LDAP data. For example, if your site has deployed a master/slave LDAP configuration, with Calendar Server accessing the master LDAP directory through a slave LDAP directory server, it introduces a delay.

This section covers the following topics:

Considerations for

Use these guidelines to determine if your site should configure the LDAP data cache:

Using the LDAP Data Cache in a Master/Slave LDAP Configuration

A Master/Slave LDAP configuration includes a master (root) directory server and one or more slave (consumer or replica) directory servers. Calendar Server can access the master LDAP directory server either directly or through a slave directory server:

LDAP Attributes Affected by Delays

If the delay in updating the slave directory servers is short (only a few seconds), clients might not experience a problem. However, if the delay is longer (minutes or hours), clients will display inaccurate LDAP data for the length of the delay.

The following table lists the LDAP attributes that are affected by a delay in a master/slave LDAP server configuration where Calendar Server accesses the master LDAP directory server through a slave LDAP directory server.

Table 18–1 Calendar Server LDAP Attributes Affected by Delays


LDAP Attributes Affected  

Auto provisioning 

icsCalendar, icsSubscribed, icsCalendarOwned, icsDWPHost

Calendar groups 


Calendar creation 

icsCalendarOwned, icsSubscribed

Calendar subscription 


User options 

icsExtendedUserPrefs, icsFirstDay, icsTimeZone, icsFreeBusy

Calendar searches 


To ensure that your end uses have the most recent LDAP data, configure the LDAP data cache as described in the following section, Resolving the Master-Slave Delay Problem.

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:

Thus, the LDAP data cache database provides for:

Limitations to the LDAP Data Cache Solution

The LDAP data cache does not provide for:

Configuring the LDAP Data Cache

Configure the LDAP data cache by setting the appropriate parameters in the ics.conf file. See the Sun Java System Calendar Server 6.3 Administration Guide for more information.

Caution – Caution –

If Calendar Server or the server where Calendar Server is running is not properly shut down, manually delete all files in the ldap_cache directory to avoid any database corruption that might cause problems during a subsequent restart.