wissel.net :: Reader fields for large user populations (Extreme Edition 2.0)

Domino Upgrade

Version	Support end
5.0
6.0
6.5
7.0

Upgrade to 8.5x now!
(see the full Lotus lifcyle) To make your upgrade a success use the Upgrade Cheat Sheet. Contemplating to replace Notes? You have to read this!

Twitter

Languages

Other languages on request.

Useful Tools

The last attempt to work with large number of entries in reader fields didn't work that well, so I try again. Andre suggested to limit the number of entries for performance (and after all if there is any breathing human inside the little yellow bubble understanding Domino performance it is him): "The other thing to think about is performance. When a user opens a view, the server has to decide which documents they have access to. So it takes a list of their groups and roles, and compares each of them to the Readers list of each document. If the user is in 30 groups and there are 500 values in the Readers field, that's 6000 string comparisons to determine that the user doesn't have access to one document. Multiply that by the number of documents in the view." So here is the plan:

The class signature stays the same as in the previous version. Signature means: the properties and methods and their parameters
Every application gets an unique identifier, so distinct group names can be build
Once the number of entries reaches a threshold automatically groups are created in the NAB (That group creation for sure could be subject to great debate. Here are the options I was thinking about:
- Allow direct access to the NAB to create/update groups. This option is feasible when the class is used for a web query save agent and the agent signer has sufficient rights
- Store the names in Names fields and have a separate "When documents have been created or changed" agent process the changes
- Use a "Run-on-server" agent and provide the document via the agent context (This also requires to "buffer" the names in Names fields
- Use a web service to update the NAB
- Use a mail-in database to handle request
The DocumentUniqueIDs of all documents in use are recorded, so access becomes much faster (getDocumentByUniversalid vs. getFirstDocumentByKey)
Not considered: check for duplicate groups - as in: check if a group with the same members. That would open a Pandora's box of checks: what to do if one document alters the group?

I updated the class and implemented "direct NAB update" and "mail-in a change request". The class picks on the basis of access to the NAB. Currently it works for server databases only (not local replicas, some more logic needed there) and it doesn't capture the UNIDs of the group documents. Further more it is lacking better error handling and documentation. Have a look at the modified class.
As usual: YMMV.

Comments

1 - "Not considered: check for duplicate groups - as in: check if a group with the same members. That would open a Pandora's box of checks: what to do if one document alters the group?"

If the objective is to create groups that exclude everyone except a small group of people, you could avoid dups by setting the UNID of the group document to be the hash of the name(s) you're excluding. That would make it easy to check whether you've already created a group for "not Stephan".

By the way, I would definitely implement a separate directory for this, and then trust it's groups via dirasst.

Posted by Nathan T. Freeman At 21:43:54 On 08/17/2009 | - Website - |