Allow trying to acquire, ping many locks in one call

[alechenninger]

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]

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" notifications@github.com 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]

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 notifications@github.com
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" notifications@github.com
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]

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" notifications@github.com 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 notifications@github.com
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" notifications@github.com
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
.