-
Notifications
You must be signed in to change notification settings - Fork 4
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
Support sharing vault locks and transactions across RPC calls #786
Comments
Did you review the js-async-locks and js-resources capabilities? |
I didn't review them but they haven't changed since I last used them AFAIK. |
This may need to be understood in the context of the new Unix commands then. |
If we need to compose multiple RPC calls, then we should do this in a single handler instead of exposing this functionality. Closing this as unplanned. |
I don't know what this has to do with multiple RPC calls? |
When I wrote this up I planned for the possibility of combining multiple plumbing RPC calls in a single CLI command. These calls needed to share a transaction and lock between them which is what this issue is about. Since writing this up I'm decided that's a bit too complex for little benefit so we're changing tac. |
Right yes, well combining RPC calls within the same transaction context isn't exactly that weird. We have the ability to maintain a stream, and that stream's liveness represents the transaction life cycle. So basically you have to execute an RPC conversation, we designed the js-rpc to be capable of this, where you can start an RPC call, and have rpc calls run within the lifecycle of the oevrall RPC call. |
Specification
With the work being done on the MatrixAI/Polykey-CLI#32 . We're starting to run into a common problem. Each of the Unix style commands have some commonality between them. Such as reading and writing entire file trees and their contents. So it makes sense to break them down into common plumbing style handlers for doing parts or each commands operations on vaults.
A clear example of this is the ls command in MatrixAI/Polykey-CLI#245. Where we can get just the file tree from the
globWalk
utility as one RPC call. And if needed we can get the file tree contents of files with a separate RPC call. The main problem here is that currently can't share the locking or transaction between these RPC calls.To fix this we need to create an RPC handler and add support to the vaults domain for this.There are two levels of locking we need. The vault level locking where we get access to the vault we wish to use. And the EFS level locking where we call read or write. The vault.write is a more complex form of this since it locks and does some modification when done. This can all be handled within a
ResourceAcquire
pattern.To address this we need to do the following.
ResourceAcquire
support forVaultManager
andVaultInternal
. We need to access theResourceAcquire
for getting a lock of the vaults and making reads/writes to vaults. This is required for allowing us to acquire the resources we need and keep them in an object map for later use.VaultManager
that allows acquiring the vault and read/write resources and then returns a resource ID that can be used to access the resource. I'm a bit fuzzy on how the two layers of locks will interact here so there may be complications. If no resourceID is provided then create a new one. If a resourceID is provided then use the existing on in the map for that id. If not resource exists for that ID then throw an error. If all uses of the resource are released then release the resource.ClientHandler
RPC handler.globWalk
utility and the one wrapping the content serialise need to optionally take the resource ID. If no id is provided then they will acquire their own lock separately. If a ID is provided then they will share the lock and transaction of the vault between the calls.Additional context
pk secrets *
Polykey-CLI#32secrets ls
command Polykey-CLI#245Tasks
ResourceAcquire
support inVaultManager
.ResourceAcquire
support inVaultInternal
.VaultManager
for acquiring and reusing locks and transactions.The text was updated successfully, but these errors were encountered: