-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object map locks should be removed in favour of transaction locks #443
Comments
The #382 should be done first before this so we can have proper verification of our concurrent behaviour now. Removing the object map locks means we should still verify whether our mutation doesn't have any race conditions during in-memory object creation. |
@tegefaulkes what object map locks do we still have?
|
I think those are the only two. |
The proxy had their object map locks replaced recently. So there were 3. Nodes and vaults still has it. @tegefaulkes can you also address the nodes change in your next PR. |
The nodes domain object maps were already replaced with |
Great so only vaults left. |
So vaults domain is the only place where it's actually replacing object map locks with transaction locks. The other 2 are just using in-memory lockbox. |
@tegefaulkes is the vaults domain still using object map locks or has it been transitioned to If it has been transitioned, this should be closed. |
I think vaults was updated with c256620. There may be an object map in the |
Ok since that is to be removed, then this is closed. |
Specification
We should remove all the object map locks in favour of the transaction locks. This is because locks don't compose, and all the object maps are just representations of the source of truth on disk. Ideally we should use the
tran.queueSuccess
and such that can do in-memory changes only after a commit occurs. This means local state inside a transactional function is temporary, and only after a commit succeeds, does global (domain state) get mutated.Generally I reckon we shouldn't have any operations that is mutating the in-memory state without also involving the underlying disk, so there shouldn't be a situation where they can't coordinate with the transaction locks.
The transaction locks are far more useful generally because they are re-entrant, and they don't release until transaction destruction.
Originally posted by @CMCDragonkai in #419 (comment)
Additional context
queueFinally
.Tasks
queueFinally
The text was updated successfully, but these errors were encountered: