Grouper Developers Forum

[Shilen Patel <>]

Hi all,

For 1.5, we're working on addressing some of the performance issues  
with effective memberships.  Part of that will mean moving the  
effective memberships out of the grouper_memberships table.  Doing  
this potentially brings us a step closer to solving another problem.

The issue is that if two processes write immediate memberships for the  
same member, group/stem, and field before either can do a commit, then  
we'll end up with two identical membership records in the database.

See --

https://bugs.internet2.edu/jira/browse/GRP-47
https://bugs.internet2.edu/jira/browse/GRP-79
https://bugs.internet2.edu/jira/browse/GRP-224


So one way to solve this would be to use locking on groups and stems  
during immediate membership adds.

But I think it would be better if we could have a unique constraint on  
the grouper_memberships table that would just prevent this from  
happening.  However, some databases don't honor unique constraints if  
part of the key contains a NULL value.  The table has columns  
owner_group_id and owner_stem_id since a membership can either be for  
a group or a stem and exactly one of the two will always be NULL.

So one way to handle this issue (proposed by Chris) would be to add  
two more columns (owner_group_id_nulls and owner_stem_id_nulls).   
These new columns would be identical to owner_group_id and  
owner_stem_id except if there's a NULL, we would put some string  
("<NULL>") in the column instead.  There would be no foreign keys on  
these columns (owner_group_id and owner_stem_id have foreign keys),  
but the unique constraint would work using the new columns.

Does anyone have any thoughts or suggestions?

Thanks!

-- Shilen