The Referral Service

A referral service uses an interceptor to trap and alter the behavior of operations effected by referrals. The behavioral modifications are triggered by the absence of the ManageDsaIT request control and/or the value of the Context.REFERRAL environment property.

Referral Name LUT

Most operations effected by referrals need to walk the ancestry of the target node. This is done to determine if a referral exists between the target node and the root vertex of the nearest context. This can get very expensive if each ancestor DN must be followed by an entry lookup to check the entry's objectClass for a referral value. The search response would slow down with such lookups. This is why the ReferralService maintains a simple referral name lookup table.

On startup, the ReferralService queries each partition mounted in the system for referrals. A simple search on each partition is conducted:

filter: '(objectClass=referral)'
scope: subtree
namesOnly: true

This search based on objectClass, is almost always guaranteed to be index driven. The search will take time but it will occur very rapidly especially since entries are not being pulled out of partitions. Each matching entry's DN is normalized. The normalized DN is added to a HashSet. After startup, during the solid state the interceptor for the ReferralService detects alterations, additions, and deletions to maintain the integrity of the Referral Name LUT.

"Hot Partition (Un)Mounting Leads to Inconsistency" Right now there is an experimental feature that allows partitions to be hot mounted and dismounted. There is no event notification that occurs to inform of the new partition's attachment to the nexus. When this happens the referral name cache will most likely become inconsistent. This can be fixed later by having the ReferralService register for hot partition mounts and dismounts.