External Change Log

The External Change Log (ECL) provides an alternative view of the replication change log. The following sections describe the architectural details of the ECL:

• How the External Change Log Works

• Porting Applications That Rely on Other Change Logs

For information about how to use the ECL, see Using the External Change Log in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

How the External Change Log Works

The ECL is built online from the replication change log and does not use an additional database for its storage. It is not a regular JEB backend, therefore no index needs to be configured.

The ECL is available by default on any server instance that includes both a directory server and a replication server. The ECL is not available on a server instance that is configured as either a dedicated directory server or a dedicated replication server (as described in Configuring Large Replication Topologies in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory).

Porting Applications That Rely on Other Change Logs

The ECL is based on the LDAP change log draft (http://tools.ietf.org/html/draft-good-ldap-changelog-04) but does not strictly support this change log. The LDAP change log draft uses an integer as the key to browse the change log whereas the ECL uses a cookie.

On the client side, the cookie mechanism has the following advantages:

• Ability to fail-over from one ECL instance to another

• Ability to load balance request over several ECL instances

On the server side, the cookie mechanism has the following advantages:

• Easier implementation in a multi-master environment

• Cheaper in terms of resources required on the server

• Smaller performance impact for other applications that generate changes

Differences Between the ECL and the LDAP Change Log Draft

The following sections describe the differences between the two change logs, which will assist you in porting client applications.

Index Differences

The LDAP change log draft specifies the change log index as an integer (changenumber attribute). This works well when the change log is served by a single server (which was the case at the time that the LDAP change log draft specification was written.) When the change log service supports more than one server and when failover is supported from one server to another, the integer format is not appropriate.

DIT and Schema Differences

The LDAP change log draft specifies the DN for entries in the change log as changenumber=changenumer,cn=changelog. The ECL uses the following DN for entries in the change log:

replicationcsn=replicationCSN,replication-domain-DN,cn=changelog

The ECL schema is based on the LDAP change log draft schema, however, Oracle Unified Directory manages an index in the ECL through a cookie that is opaque to the application, rather than through the changenumber attribute. The schema differ as follows:

Additional Differences Between the ECL and the Oracle Directory Server Enterprise Edition Retro Change Log

Schema and implementation-based values

The Oracle Directory Server Enterprise Edition RCL specifies that the target entry unique ID is stored in the targetuniqueid attribute. The format of this attribute value is specific to Oracle Directory Server Enterprise Edition. The replicationcsn attribute also has a value that is specific to Oracle Directory Server Enterprise Edition.

First and last ECL index

The Oracle Directory Server Enterprise Edition RCL supports the following attributes in the root DSE entry:

• The firstchangenumber attribute, which contains the first (oldest) change log index as an integer change number.

  This value is updated when the change log is purged. Before connecting to the change log server, an application reads the first change log index and compares it with the change log index that it stored. If the first change log index is more recent than the last change log index stored by the application, the application knows that the changes from the application index to the first change log index will never be returned by the server. They can only be obtained by reading the entries (full resync).

  With the Oracle Unified Directory ECL, this procedure is not required of the application. Instead the Oracle Unified Directory server does the check and rejects the request when the cookie is too old. For more information, see Using the External Change Log in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

• The lastchangenumber attribute, which contains the latest (newest) change log index as an integer change number.

  The Oracle Unified Directory ECL supports the equivalent feature with the lastExternalChangelogCookie attribute. For more information, see Using the External Change Log in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

Purge delay

In the Oracle Directory Server Enterprise Edition RCL, the external change log and the regular replication change log are different databases. In Oracle Unified Directory, the two change logs are in the same database. This design decision has several advantages. An additional consequence of this design decision is that Oracle Directory Server Enterprise Edition can have two different trim policies (purge delays), while in Oracle Unified Directory the trim policy is the same.

API for Compatibility With the LDAP Change Log Draft and the Oracle Directory Server Enterprise Edition Retro Change Log

Oracle Unified Directory provides an additional API that is compatible with the LDAP draft change log and supports most of the additional features of the Oracle Directory Server Enterprise Edition Retro Change Log. The use of this API has a performance impact in terms of CPU and database (disk) space on the server side, and some computation for the application that fails over from one ECL server to another one.

The use of this compatible API (compatible mode) is configured when the server receives a request on the ECL with no change log cookie. The server returns entries with a changenumber attribute, the value of which is an incremental integer.

The client can search the ECL by providing a filter on the changenumber. The target entry unique ID is stored in an attribute called targetuniqueid with a format compatible with the Oracle Directory Server Enterprise Edition Retro Change Log. The first and last changenumber are present as attributes of the root DSE entry.

Limitations of the Compability API

Because Oracle Unified Directory does not store the ECL in a dedicated database, it does not support all the features supported by a JEB back end, such as specific indexes.

In addition, in order to support the changenumber-based ordering that is specified by the LDAP change log draft, Oracle Unified Directory must store a mapping from the changenumber to the replication state. When the server processes a request, it must try to retrieve the replication state from the changenumber that is provided in the request filter. If this cannot be achieved, the request is rejected.