Re: dynamic group caching

[Aleksander Adamowski <aleksander.adamowski@altkom.pl>]

Pierangelo Masarati wrote:
> Probably a simpler approach would be to have a different type of dynamic
> group that's rather a "cachedGroup"; a background thread could take care
> of keeping it updated by expanding dynamic members into static (and
> indexed), while direct modifications could be trapped and handled
> explicitly (e.g. if a memberURL is added/removed).  The drawback would
> be that other updates to the database (like another user entering the
> scope of a memberURL search) are not immediately reflected in group
> membership.  Static members should also be treated specially; this could
> be perhaps be done by subtyping the dynamically cached members from the
> static ones, so that regular searches for the static member attribute
> find both, but caching operations only deal with the dynamically
> generated ones.
>   
This approach would definitely be simpler, but I see 2 deficiencies:

   1. For large directories, the background thread scanning the whole
      database over and over could become a serious performance parasite
   2. The thread could do the task very slowly and dynamic group data
      would be often stale, causing all sorts of problems, especially
      with objects which have their DNs changed.

Ad 2. - I can imagine lots of problems spanning from this - e.g. when a
user is moved to a different subtree (e.g. the directory structure is
based on localities, and a user moves to a different city), until the
background thread updates the static member list, he loses any rights
stemming from his dynamic group memberships, because he works with a new
DN, while the static member lists are still using the old one.
That's also a problem with ordinary static groups, but in their case the
directory management tools usually take care of maintaining referential
integrity, while there will be no way to order the background thread to
refresh the groups immediately (or do it faster than currently if it
runs continuously).

The approach I've suggested is definitely quite hard, and I can see that
even commercial directory servers usually hava an Achilles feet WRT
dynamic groups here, but it would provide the exact functionality that
the user expects, without any gotchas. Maybe I won't succeed in
implementing it, but it's worth trying (or considering at least).



--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    
    kom. 0-601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete all copies of this message.