Rather than make an iffy addition to the UserDirectoryService interface, I'm backing this out of the working branch.

Removed at revision: 34776.

Closer analysis makes me suspect that adding this call will provide very little relief for the targeted use case. It's true that currently there's no way for code to take advantage of the UserDirectoryProvider "getUsers(userShells)" method until after provided users are mapped with Sakai IDs. But most of that overhead has been eliminated by the recent caching of the EID-ID map.

I tested on the out-of-the-box demo system, which I used to create a course site with 187 members (including instructor), With the most recent changes, the biggest impact as regards initial EID mapping comes from the mapping table inserts themselves (6 seconds). But that's about the same as the cost of the SAKAI_SITE_USER inserts, and there's not much to be done about INSERT costs except to redesign the system to require fewer inserts.

(For the record, what creates the mapping at present is DbAuthzGroupService$DbStorage refreshAuthzGroup, which calls "getUserId(userEid)" in a loop of the results of "m_provider.getUserRolesForGroup(realm.getProviderGroupId())".)

At this point, well more than half the 40 second cost of the course site creation is due to the authz/group system. Creating this single site caused 827 SAKAI_REALM_RL_FN inserts and 581 SAKAI_REALM_RL_GR inserts.

It's possible that while the user record cache is being filled, there may be some performance improvement for user directory providers who bother to use "SELECT ... WHERE ... IN (...)" statements. Otherwise, I'm skeptical. Along similar lines, I notice that the JA-SIG PersonDirectory only supports one-at-a-time access.

And so, having coded this, I'm no longer sure it's worth adding it to the trunk and increasing the complexity of services which stand in need of more drastic rethinking. Comments pro or con are welcome!

Added Collection<User> getUsersByEid(Collection<String> eids) to UserDirectoryService and cover at revision: 34669.

I'm waiting to get confirmation from Aaron on the targeted use case. After that, I'll try changing one of the applicable clients to use the new service method before officially wrapping this up.

As described by Aaron Zeckoski in SAK-10418:

One thing we need to find ASAP is the issue with being unable to look up a user using the bulk method if they have never logged into Sakai before (or have never had an account created in Sakai before). The bulk method I am referring to is getUsers(collection) and the issue is that it always attempts to look up the eid for the passed in ids (which are likely to be eids if the user never existed in Sakai) and then throws an error if the eid cannot be found internally. This is unfortunate and means that the bulk method can only be used for internal userids.