Terry, thanks for the quick response and explanation. This design is good
for our large consortium (University of Wisconsin System) because it
reduces the likelihood of batch updates having an impact on more critically
time sensitive API requests like displaying a patron account, placing
requests for items or processing patron record updates.

On Mon, Aug 28, 2017 at 11:34 AM, Terry Reese <[log in to unmask]> wrote:

> I can answer that question -- they are not multi-threaded.  Search is done
> via Z39.50 or SRU (though, the record itself must be pulled via the API in
> order to get the IDs), and then updates must happen on a record by record
> bases (so again, one call per record) via the API.  Each record is handled
> individually, and procedurally because the ability for alma to handle
> threaded updates seemed to vary by institution.  Taking the slower (but
> more reliable approach) seemed best.
>
> You can see the API code here: https://github.com/reeset/alma_api_library
>
> FYI -- I'll be changing it slightly to accommodate a few changes to the
> Alma api happening in September.
>
> --tr
>
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Steve Meyer
> Sent: Monday, August 28, 2017 12:20 PM
> To: [log in to unmask]
> Subject: [CODE4LIB] Are MarcEdit Alma API requests multi-threaded?
>
> We are investigating using Marc4Edit to batch update MARC records in Alma
> via the Alma APIs.
>
> I realize this question is likely more appropriate for the MarcEdit
> listserv, but I am asking from the perspective of our systems and
> development departments, not as the MarcEdit users in our cataloging
> departments. We are concerned about API throttling, quotas and the impact
> on multiple API requests against Alma.
>
> The Alma APIs are rate limited; so before embarking on this approach, we'd
> like to make sure we don't hit our API quotas. Can anyone tell us if
> Marc4Edit's Alma bib record write operations are multi-threaded, and if so,
> is there any way to configure the number of threads spawned?
>
> We could end up in a situation where other critical systems that
> communicate with Alma via its APIs could become unavailable due to our API
> account being flooded with what is actually a lower priority set of
> requests.
>
> Thanks,
> Steve
>