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
