directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Subentry cache : one step further
Date Sun, 02 Jan 2011 23:27:51 GMT
Hi,

today, I modified the SubentryCache to offer an opaque class which hide 
the inner data structure. In other words, this cache now handles both 
the UUID -> Subentry and DN -> Suentry caches internally, because there 
is no reason that the user knows about the internals.

That led to a lot of modifications in the Subentry interceptor, but at 
least, I got almost all the add/delete/lokup tests working back again - 
except 2 -. I will fix the last two tests tomorrow morning, it should 
not take too long.

I believe the next data structures and mechanisms to add/delete 
subentries, entries and AP are now working fine, and that we can 
successfully implement the remaining operations fast.

In the mean time, it was clear that we had problems in the current trunk :
- the referrals were almost certainly badly managed, as there is no move 
operation for the DnNode class, which is used to cache referrals. A JIRA 
has been created
- I'm almost sure that the trunk (or even the previous versions) didn't 
handled correctly subentries in many cases, as the cache was really 
simplistic. That does not matter too much, assuming that the branch we 
are working on will fix this.
- We also need to make the DnNode structure and SubentryCache threadSafe 
( a JIRA has been created for that)

Hopefully, not only we will have a full support for AAP, SAP and IAP in 
the close future, but I expect to have a more solid implementation, with 
more tests to check that we cover most of the possible cases (it might 
take a bit more time). Last, ot least, it should be fast, once the 
entries are updated. (I still have in mind to add an optional 
computation of the entries when an AP or a Subentry are modified, to 
avoid a postponed evaluation).

That's it, just wanted to update you guys.

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message