Comment 14 for bug 1821094

I've tested the patch and it does indeed make updates of the item status grid faster. However, I've observed a tradeoff: when you do the update (or for that matter, when you load the holdings editor with 100+ items, although that's not a concern of this particular patch), it's easy to fire off so many PCRUD requests simultaneously that the pool of open-ils.pcrud backends get saturated.

With the OpenSRF 3.1 request backlog queue, that's not a big deal in the sense that ultimately every request will get handled. However, for as long as open-ils.pcrud is in backlog mode, _all_ PCRUD requests will get queued, which will make other webstaff interlaces slower system-wide.

I think we should look into finding some way to run the PCRUD promises emitted by ItemSvc and friends with a concurrency that is more than one (i.e., chaining them sequentially) but less than infinity so that somebody doing batch work in the Item Status interface is less likely to monopolize PCRUD backends.

A starting point for thinking about how to implement this might be https://glebbahmutov.com/blog/run-n-promises-in-parallel/.