Subsription tracking refactoring #215
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
00nktk
requested changes
Nov 22, 2021
There was a problem hiding this comment.
Вроде должно работать, но можно еще лучше скрыть менеджинг ссылок внутри ProgramAccountsDb.
Одна из серьезных проблем - подчистка подписок на аккаунты, которые принадлежат программе, но не вошли в запрос, который стригеррил подписку на программу. Думаю, можно вынести в отдельный ишью и там обсудить как лучше сделать.
00nktk
requested changes
Nov 26, 2021
00nktk
reviewed
Nov 30, 2021
polachok
reviewed
Dec 1, 2021
00nktk
approved these changes
Dec 2, 2021
polachok
approved these changes
Dec 2, 2021
1. When getAccount info triggers subscription, account key starts being tracked in ProgramAccountsDB, for further transfer of tracking control to owner program. 2. If during subscription attempt for account, it's found that owner program already has cache entry and subscription, then no new account subscription is created, but account key is still added to the list of tracked keys. 3. When getProgramAccouns gets cached, it unsubscribes from all tracked accounts. 4. All accounts, which are being tracked by ProgramAccountsDB, get's served from cache, as long as parent has an active subscription, and do not create their own subscription. 5. When getAccountInfo hits the cache it creates a purge task for itself, and when timer expires, it removes itself from tracked accounts in ProgramAccountsDB, and tries to remove itself from AccountsDB cache, succeeding only if no program filters hold another reference count to it. 6. When getAccountInfo misses the cache, while it's owner still having active subscription, the result is similar to case 3, it fetches account by RPC, puts it into AccountsDB, starts tracking it in ProgramAccountsDB, and doesn't create extra subscription for itself, while still spawning purge task to be removed later. Co-authored-by: Alexander Polakov <a.polakov@zubr.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
accounts, but starts tracking their reference counts, to prevent
premature removal.
served from cache, as long as parent has an active subscription, and
do not create their own subscription.
itself, and when timer expires, it removes itself from tracked
accounts in ProgramAccountsDB, and tries to remove itself from
AccountsDB cache, succeeding only if no program filters hold another
reference count to it.
active subscription, the result is similar to case 3, it fetches
account by RPC, puts it into AccountsDB, starts tracking it in
ProgramAccountsDB, and doesn't create extra subscription for itself,
while still spawning purge task to be removed later.