Grouper Developers Forum

[Tom Barton <>]

Can you tell whether the Brown approach to the time/space trade-off is 
likely to yield a similar performance gain as your approach? If there's 
reason to believe so, it seems a simpler approach, ie, with fewer moving 
parts.

A few questions regarding the database-in-the-middle approach:

1. Would it be necessary to also build a utility to initialize that 
database to be a snapshot of current LDAP-resident group information?

2. What about ldappc implementations in which one instance is 
provisioning a subset of the groups registry to LDAP? Is there an issue 
with specifying how the middle database should be initialized? How about 
if two or more ldappc instances are each provisioning disjoint slices of 
the groups registry?

Kathryn Huxtable wrote:
> For ldappc version 1.0.1 I propose that the main changes be in improving 
> performance.
>
> My approach when I was at KU was to create a table in an RDBMS 
> containing group/subject tuples and provision the table instead of LDAP. 
> Since KU provisions everything in LDAP from RDBMS tables, this used KU’s 
> usual provisioning to propagate this data into LDAP and keep it 
> synchronized.
>
> Also, I used more memory than the existing code and pulled an entire 
> group’s subjects into memory and compared it with the RDBMS table and 
> then just made changes. This is a more practical approach to the 
> time/space tradeoff in today’s world where memory is cheap and we want 
> fast performance. The ldappc source makes the opposite decision and, to 
> the authors’ credit, documents it.
>
> Brown’s approach has been very similar in terms of time/space, but they 
> directly query LDAP and make the changes there. There are some 
> implementation differences between my KU code and Brown’s, but the 
> concepts are congruent and the performance enhancement similar.
>
> My experience at KU was that although querying LDAP had good performance 
> for groups, querying for memberships had very poor performance. It’s 
> possible that KU’s LDAP was out of cache space for the people branch. KU 
> was having some LDAP performance problems at the time. Since KU always 
> masters everything in an RDBMS anyway, this made the choice of a 
> database table with a separate synchronization with LDAP a natural 
> approach.
>
> I’m willing to do this either way, with or without a database table. 
> I’ll change the comparison and update code to reflect either my approach 
> or, with Brown’s permission, Brown’s approach, depending on which one 
> gives the best performance when abstracted and tested against some 
> random test data sets.
>
> If I use a database table, my plan is to embed a Derby database by 
> default but allow the user to configure any alternate database of their 
> choice. That way, this could still be adapted to KU’s use or could be 
> used to feed Sun Identity Manager or Novell Identity Manager (where 
> used) from the table, providing good integration with commercial IDMS 
> products.
>
> Has anyone else had “bad” performance querying their people branch for 
> subjects with particular isMemberOf values. (Or any other indexed 
> attribute other than RDN?)
>
> What do people think? And if this sounds good, with or without a 
> database table?
>
> -K
>
> PS: For ldappc version 2.0 I propose a more extensive refactoring of the 
> code to support multiple plugins to provision things other than LDAP. I 
> might actually propose that the name of the product be changed to rbacpc 
> (role based access control provisioning connector). I have ideas about 
> this, but let's get the work started on ldappc 1.0.1 first.