directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Creation of a second Subentry cache
Date Sun, 02 Jan 2011 09:36:26 GMT
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 
(https://issues.apache.org/jira/browse/DIRSHARED-72 and 
https://issues.apache.org/jira/browse/DIRSHARED-73) 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
www.iktek.com


Mime
View raw message