We want to guarantee that we preserve ordering of workers to requests.
lock is used to try to prevent multiple coroutines from accessing a shared resource at the same time,
which can result in race conditions and data inconsistency.
This code actually doesn't do it though, since we aren't giving out a slot, it is still somewhat a race condition.
The ideal solution is likely that each thread grabs the next number from a incremental integer.
When they complete, they increment that number and that entity is able to enter the lock.
That would guarantee ordering.
maxWaitTime
maxWaitTime:number
maximumInFlight
maximumInFlight:number
sleepTime
sleepTime:number
Methods
initialize
initialize(): Promise<void>
Initializes this account with the sequence number on chain
Returns Promise<void>
nextSequenceNumber
nextSequenceNumber(): Promise<null | bigint>
Returns the next available sequence number for this account
Returns Promise<null | bigint>
next available sequence number
synchronize
synchronize(): Promise<void>
Synchronizes local sequence number with the seqeunce number on chain for this account.
Poll the network until all submitted transactions have either been committed or until
the maximum wait time has elapsed
Returns Promise<void>
update
update(): Promise<bigint>
Updates this account sequence number with the one on-chain
We want to guarantee that we preserve ordering of workers to requests.
lockis used to try to prevent multiple coroutines from accessing a shared resource at the same time, which can result in race conditions and data inconsistency. This code actually doesn't do it though, since we aren't giving out a slot, it is still somewhat a race condition.The ideal solution is likely that each thread grabs the next number from a incremental integer. When they complete, they increment that number and that entity is able to enter the
lock. That would guarantee ordering.