directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Creation of a second Subentry cache
Date Sun, 02 Jan 2011 15:05:22 GMT

The dn2subentry cache sounds like a valid optimization and making it a  
top level accesible cache also sounds right.

Additionally i checked out depa on DnNode and it seems out of place in  
shared. Had the thought that it might be best close to where it is  
being used.  WDYT?

Sent from my iPhone

On Jan 2, 2011, at 11:36 AM, Emmanuel Lecharny <>  

> Hi,
> we currently use a UUID -> Subentry cache, used for the most common  
> operations like retrieving a subentry when processing an entry (as  
> we store the subentry's UUID in an entry selected by the subentry  
> SubtreeSpecification, to avoid some costly operations on disk  
> following a ModDN operation).
> That's ok, and enough, except that when we add an entry, we have to  
> check that it's not added under a subentry (no entries are allowed  
> under a subentry). How do we do that ? If we don't have a DN ->  
> Subentry cache, that means we have to either read the added entry's  
> parent, and check if it's not a subentry. Costly, and not  
> convenient. There are also many other operations for which we would  
> like to retrieve a subentry directly from its DN, not its UUID, like  
> when we delete a subentry (we just get its DN, so we have to do  
> either a lookup to get it back in order to retrieve its reference in  
> the UUID -> Subentry cache, or fetch the AP and look into all the  
> associated Subentries to get back its UUID. Painful).
> So I will create a second cache, a DN -> Subentry that will help to  
> manipulate the subentries.
> I have created two JIRAs ( and

> ) which are closely related to the DnNode data structure in order to  
> be able to easily handle a ModDN operation, as such an operation is  
> not supported by the data structure (and as a side effect, if we do  
> a ModDN on a referral or on its parents, the referral won't be  
> cached anymore). The other JIRA is to make this structure thread safe.
> One more requirement : at some point, we may want to make the  
> subentryCache a unique data structure handling the two types of  
> cache internally. That will probably be the next step.
> -- 
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message