Skip to content
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

Allow trying to acquire, ping many locks in one call #244

Open
alechenninger opened this issue Jun 30, 2016 · 3 comments
Open

Allow trying to acquire, ping many locks in one call #244

alechenninger opened this issue Jun 30, 2016 · 3 comments

Comments

@alechenninger
Copy link
Contributor

We have algorithms we require us to acquire a bunch of locks, and we do these in a loop, which forces us to suffer the network round trip for each call. We could parallelize these, true, but it is probably easy to add this to the rest interface also so that we can pass many locks to acquire in one call, with a response that says what locks were successfully acquired and what locks weren't.

Maybe it would be worth reusing the bulk endpoint for this? It's essentially a bulk request but for locks.

@bserdar thoughts?

@bserdar
Copy link
Contributor

bserdar commented Jun 30, 2016

There are some problems. Do you want all or none, or do you want best
effort? That's why bulk lock requests are not supported.

Best effort is easy to implement, all or none is not. In any case, this has
to be handled in a separate type of call, not bulk call.
On Jun 29, 2016 5:35 PM, "Alec Henninger" [email protected] wrote:

We have algorithms we require us to acquire a bunch of locks, and we do
these in a loop, which forces us to suffer the network round trip for each
call. We could parallelize these, true, but it is probably easy to add this
to the rest interface also so that we can pass many locks to acquire in one
call, with a response that says what locks were successfully acquired and
what locks weren't.

Maybe it would be worth reusing the bulk endpoint for this? It's
essentially a bulk request but for locks.

@bserdar https://github.com/bserdar thoughts?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#244, or mute
the thread
https://github.com/notifications/unsubscribe/ADgDDcvJOqlQLqRtZCy_CqBg3jrL-Dz3ks5qQw9QgaJpZM4JBswd
.

@alechenninger
Copy link
Contributor Author

Just want best effort, same as you would get if you made many separate
calls. The goal is just to save on excess IO, same semantics otherwise are
fine.

On Wed, Jun 29, 2016 at 9:39 PM Burak Serdar [email protected]
wrote:

There are some problems. Do you want all or none, or do you want best
effort? That's why bulk lock requests are not supported.

Best effort is easy to implement, all or none is not. In any case, this has
to be handled in a separate type of call, not bulk call.
On Jun 29, 2016 5:35 PM, "Alec Henninger" [email protected]
wrote:

We have algorithms we require us to acquire a bunch of locks, and we do
these in a loop, which forces us to suffer the network round trip for
each
call. We could parallelize these, true, but it is probably easy to add
this
to the rest interface also so that we can pass many locks to acquire in
one
call, with a response that says what locks were successfully acquired and
what locks weren't.

Maybe it would be worth reusing the bulk endpoint for this? It's
essentially a bulk request but for locks.

@bserdar https://github.com/bserdar thoughts?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#244, or
mute
the thread
<
https://github.com/notifications/unsubscribe/ADgDDcvJOqlQLqRtZCy_CqBg3jrL-Dz3ks5qQw9QgaJpZM4JBswd

.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#244 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADVabxgwRR0xkx5EhdknuUN5NCec--h1ks5qQx5XgaJpZM4JBswd
.

@bserdar
Copy link
Contributor

bserdar commented Jun 30, 2016

Lets make that a separate api. A bulk request mixed with both crud
operations and synchronization primitives, when submitted as an ordered
bulk request, looks too much like a sequence of operations with memory
barriers.
On Jun 29, 2016 7:33 PM, "Alec Henninger" [email protected] wrote:

Just want best effort, same as you would get if you made many separate
calls. The goal is just to save on excess IO, same semantics otherwise are
fine.

On Wed, Jun 29, 2016 at 9:39 PM Burak Serdar [email protected]
wrote:

There are some problems. Do you want all or none, or do you want best
effort? That's why bulk lock requests are not supported.

Best effort is easy to implement, all or none is not. In any case, this
has
to be handled in a separate type of call, not bulk call.
On Jun 29, 2016 5:35 PM, "Alec Henninger" [email protected]
wrote:

We have algorithms we require us to acquire a bunch of locks, and we do
these in a loop, which forces us to suffer the network round trip for
each
call. We could parallelize these, true, but it is probably easy to add
this
to the rest interface also so that we can pass many locks to acquire in
one
call, with a response that says what locks were successfully acquired
and
what locks weren't.

Maybe it would be worth reusing the bulk endpoint for this? It's
essentially a bulk request but for locks.

@bserdar https://github.com/bserdar thoughts?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#244, or
mute
the thread
<

https://github.com/notifications/unsubscribe/ADgDDcvJOqlQLqRtZCy_CqBg3jrL-Dz3ks5qQw9QgaJpZM4JBswd

.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
#244 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ADVabxgwRR0xkx5EhdknuUN5NCec--h1ks5qQx5XgaJpZM4JBswd

.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#244 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADgDDdNZMZkxGX5jyFLAcnS0toSX0EZQks5qQysKgaJpZM4JBswd
.

@alechenninger alechenninger changed the title Allow trying to acquire many locks in one call Allow trying to acquire, ping many locks in one call Oct 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants