https://netsuiteprofessionals.com logo
Join Slack
Powered by
My multithreaded programming is poor at best. I ha...
# suitescript
e
My multithreaded programming is poor at best. I have a long-running (on the scale of hours) Map/Reduce that calls out to an external API and uses OAuth tokens. The runtime is overwhelmingly spent in the 
reduce
stage. The token expires every two hours and must be refreshed. Right now, I've limited the script to a single processor as I can't figure out how I might prevent a race condition between processors simultaneously sending the refresh request, or narrowly missing the refresh window, or erroring out if they send out their normal API call while the token is being refreshed. With the many thousands of records I'm processing and only 4 processors, I have to imagine this race condition would occur almost every refresh cycle. Any suggestions on ensuring only a single refresh request goes out even if multiple processors recognize the need to refresh the token all at once?
b
checkout section 4.7 SuiteApp Designs and Concurrency Issues from the SAFE guide
👍 1
it offers 2 techniques for handling race conditions, i like the opportunistic locking one
👍 1
e
Hm interesting; could just completely pull out the refresh process into a scheduled script.
Still potentially have a different race then, though, I suppose
A good read though, thanks
b
the idea is to use a custom record as semaphore. load a custom record and check to see if a field is set, if not then set that field and save the record, then send the refresh request, and then update the custom record when done.
if the field is set. then implement a wait function
if there is a race condition, the first record to save does the refresh while the others fail due to the opportunistic locking. failing deployments should go back to waiting
e
The problem isn't really the updating of the record though. The problem is the sending of the token refresh request
b
setup logic so that only the processor that set the field is the one that can send the refresh request
d
@erictgrubaugh I make use of caching module when it comes to refresh tokens. TTL is key
👍🏼 1
I use semaphores to manage process instantiations ... It's pretty slick
Wrapping an API in a class, then isolating the token management within has become second nature. TypeScript/OO design.
e
Where does the semaphore live?
and ^^^^ how would I know which processor is running?
If I could determine that, I would just only allow processor #1 to do the refresh
s
I would use the Cache TTL to refresh the token, as Darren Mentioned. cache.get() allows you to specify a loader function which is called when the cache value isn’t available, in the case of netsuite losing it, or the ttl expiring.
e
The problem isn't refreshing on time
s
If all of the processors utilize the cache, do you think there would still be a race condition with the auth?
Open in Slack
PreviousNext
Powered by