ReadonlyaccountReadonlyaptosWe 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.
A wrapper that handles and manages an account sequence number.
Submit up to
maximumInFlighttransactions per account in parallel with a timeout ofsleepTimeIf local assumesmaximumInFlightare in flight, determine the actual committed state from the network If there are less thanmaximumInFlightdue to some being committed, adjust the window IfmaximumInFlightare in flight, waitsleepTimeseconds before re-evaluating If ever waiting more thanmaxWaitTimerestart the sequence number to the current on-chain stateAssumptions: Accounts are expected to be managed by a single AccountSequenceNumber and not used otherwise. They are initialized to the current on-chain state, so if there are already transactions in flight, they may take some time to reset. Accounts are automatically initialized if not explicitly
Notes: This is co-routine safe, that is many async tasks can be reading from this concurrently. The state of an account cannot be used across multiple AccountSequenceNumber services. The synchronize method will create a barrier that prevents additional nextSequenceNumber calls until it is complete. This only manages the distribution of sequence numbers it does not help handle transaction failures. If a transaction fails, you should call synchronize and wait for timeouts.