Atomicity of if_not_modified?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Atomicity of if_not_modified?

qaspar
Hello,

Say I have N=3, R=2 and W=2, and two clients are simultaneously trying to update the same object with if_not_modified=true. Is there a possible scenario where both clients can succeed? If not and if at most one client succeeds then setting if_not_modified=true would be a way to atomically lock an object, right?

If this is correct then there's an additional problem: Assume the following happens when three processes try to update the same object simultaneously, with A/B/C being our three primary nodes for the object:
1. Process P1 updates A
2. Process P2 updates B
3. Process P3 updates C

Now any attempt for any of the processes to write to a second primary node (W=2) will fail because the node has been modified (as if_not_modified=true). Therefore, all three process will fail, which is fair enough. But the problem is now that we have three different 'stale' copies of the object already written to A, B and C. The next time a process wants to read the object (with R=2) Riak will find three different objects (or rather, three different vector clocks), so the read will fail, thus rendering the object 'unreadable', so I can't even use read-repair. Is my interpretation correct, and how can I work around this?

Kaspar
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Daniil Churikov
Riak doesn't have atomic updates. This if_not_modified does not gives you any guaranties. Best way to handle with simultaneously updates is try to engineer scheme so that only one client makes concurrent updates and in case of conflict any sibling will be good for you. Another option is try to use convergent data types [0][1]
[0] https://github.com/basho/riak_dt
[1] https://github.com/mochi/statebox_riak
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Kaspar Thommen

Hi,

Can someone confirm this? If it's true, what exactly is the purpose of offering the if_not_modified flag?

Kaspar

On Dec 28, 2012 1:51 PM, "Daniil Churikov" <[hidden email]> wrote:
Riak doesn't have atomic updates. This if_not_modified does not gives you any
guaranties. Best way to handle with simultaneously updates is try to
engineer scheme so that only one client makes concurrent updates and in case
of conflict any sibling will be good for you. Another option is try to use
convergent data types [0][1]
[0] https://github.com/basho/riak_dt
[1] https://github.com/mochi/statebox_riak



--
View this message in context: http://riak-users.197444.n3.nabble.com/Atomicity-of-if-not-modified-tp4026430p4026431.html
Sent from the Riak Users mailing list archive at Nabble.com.

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

qaspar
In reply to this post by Daniil Churikov

Hi,

Can someone confirm this? If it's true, what exactly is the purpose of offering the if_not_modified flag?

Kaspar

On Dec 28, 2012 1:51 PM, "Daniil Churikov [via Riak Users]" <[hidden email]> wrote:
Riak doesn't have atomic updates. This if_not_modified does not gives you any guaranties. Best way to handle with simultaneously updates is try to engineer scheme so that only one client makes concurrent updates and in case of conflict any sibling will be good for you. Another option is try to use convergent data types [0][1]
[0] https://github.com/basho/riak_dt
[1] https://github.com/mochi/statebox_riak


If you reply to this email, your message will be added to the discussion below:
http://riak-users.197444.n3.nabble.com/Atomicity-of-if-not-modified-tp4026430p4026431.html
To unsubscribe from Atomicity of if_not_modified?, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Pavan  Venkatesh
In reply to this post by qaspar

Hi,

If its through http, "ifnotmodified" will only store if there has been no modification since the provided timestamp (conditional store). 

With your example of N=3, R=2 and W=2, if two clients are updating at the same time to the same object, then it actually depends on the "allow_mult" and "last_write_wins" variable. 

Case 1-- If allow_mult is true and last_write_wins is false, then siblings are created and replicated among the nodes. It has to be resolved on the client side. Client will have to issue a "put" request later along with the vector clock and with the relevant value in order to resolve the sibling scenario.

Case 2— If  allow_mult is false and last write_wins is true, then the client with the latest time stamp wins. Siblings might occur here, but is not exposed to the client.

Case 3— If allow_mult is false and last write_wins is false, then resolve differences using vector clock(this happens internally). The latest one is returned if siblings still exists.

Case 4— If allow_mult is true and last write_wins is true, then the client with the latest time stamp wins.

More Details on "IfnotModified" below-

ifNotModified

public StoreObject<T> ifNotModified(boolean ifNotModified)
Default is false (i.e. NOT a conditional store).

NOTE: This has different meanings depending on the underlying transport.

In the case of the PB interface it means: Only store if the vclock provided with the store is the same as the one in Riak for this object (i.e. the object has not been modified since you last got it), of course, since this StoreObject does a fetch before a store the window for concurrent modification is minimized, but this is an extra guard, still.

For the HTTP API it means: Only store if there has been no modification since the provided timestamp.

To make this transparent the StoreOperation will pull the last modified date from the object returned in the pre-store fetch, and use that as supplementary data to the HTTP Store request.

Parameters:
ifNotModified - true if you want a conditional store, false otherwise, defaults to false.
Returns:
This

Pavan


From: qaspar <[hidden email]>
Date: Thursday, January 3, 2013 8:46 AM
To: <[hidden email]>
Subject: Re: Atomicity of if_not_modified?

Hi,

Can someone confirm this? If it's true, what exactly is the purpose of offering the if_not_modified flag?

Kaspar

On Dec 28, 2012 1:51 PM, "Daniil Churikov [via Riak Users]" <[hidden email]> wrote:
Riak doesn't have atomic updates. This if_not_modified does not gives you any guaranties. Best way to handle with simultaneously updates is try to engineer scheme so that only one client makes concurrent updates and in case of conflict any sibling will be good for you. Another option is try to use convergent data types [0][1]
[0] https://github.com/basho/riak_dt
[1] https://github.com/mochi/statebox_riak


If you reply to this email, your message will be added to the discussion below:
http://riak-users.197444.n3.nabble.com/Atomicity-of-if-not-modified-tp4026430p4026431.html
To unsubscribe from Atomicity of if_not_modified?, click here.
NAML


View this message in context: Re: Atomicity of if_not_modified?
Sent from the Riak Users mailing list archive at Nabble.com.
_______________________________________________ riak-users mailing list [hidden email] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Elias Levy
In reply to this post by qaspar
On Fri, Jan 4, 2013 at 9:00 AM, <[hidden email]> wrote:
From: Pavan Venkatesh <[hidden email]>

With your example of N=3, R=2 and W=2, if two clients are updating at the same time to the same object, then it actually depends on the "allow_mult" and "last_write_wins" variable. 


Correct me if I am wrong, but the caveat here is that the R must be default values for the bucket.  The internal get performed by the coordinating node handing the INM request does not actually use the R and W value of the INM request.  Correct?

It would seem advisable to change this behavior.  Maybe the R value of the internal get should match the W value of the INM request.

Elias Levy

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Les Mikesell
On Fri, Jan 4, 2013 at 11:53 AM, Elias Levy <[hidden email]> wrote:

>>>
>> With your example of N=3, R=2 and W=2, if two clients are updating at the
>> same time to the same object, then it actually depends on the "allow_mult"
>> and "last_write_wins" variable.
>
>
> Correct me if I am wrong, but the caveat here is that the R must be default
> values for the bucket.  The internal get performed by the coordinating node
> handing the INM request does not actually use the R and W value of the INM
> request.  Correct?
>
> It would seem advisable to change this behavior.  Maybe the R value of the
> internal get should match the W value of the INM request.

And, doesn't every description of riak behavior have to include the
scenario where the network is partitioned and updates are
simultaneously performed by entities that can't contact each other?
If it weren't for that possibility, it could just elect a master and
do real atomic operations.

--
   Les Mikesell
     [hidden email]

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Justin Sheehy

On Jan 4, 2013, at 1:25 PM, Les Mikesell wrote:

> And, doesn't every description of riak behavior have to include the
> scenario where the network is partitioned and updates are
> simultaneously performed by entities that can't contact each other?
> If it weren't for that possibility, it could just elect a master and
> do real atomic operations.

Yes, absolutely.

There are no atomic compare-and-set operations available from Riak, regardless of headers and R/W values.

Conditional HTTP requests are present because they are "free" due to Webmachine, and they are sometimes useful, but should not be seen as semantically very different from the client doing a read itself to decide whether to write.

-Justin



_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

qaspar
Justin Sheehy wrote
On Jan 4, 2013, at 1:25 PM, Les Mikesell wrote:

> And, doesn't every description of riak behavior have to include the
> scenario where the network is partitioned and updates are
> simultaneously performed by entities that can't contact each other?
> If it weren't for that possibility, it could just elect a master and
> do real atomic operations.

Yes, absolutely.

There are no atomic compare-and-set operations available from Riak, regardless of headers and R/W values.

Conditional HTTP requests are present because they are "free" due to Webmachine, and they are sometimes useful, but should not be seen as semantically very different from the client doing a read itself to decide whether to write.

-Justin
Agreed. But I think the split-brain scenario could be avoided by setting DW=DR=2 in addition, in which case at most one call to one of the partitions can succeed - correct?

Kaspar

Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Justin Sheehy
In reply to this post by Kaspar Thommen

On Jan 3, 2013, at 11:44 AM, Kaspar Thommen wrote:

> Can someone confirm this? If it's true, what exactly is the purpose of offering the if_not_modified flag?

Yes, I confirmed this earlier in this thread:

http://lists.basho.com/pipermail/riak-users_lists.basho.com/2013-January/010672.html

-Justin



_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

qaspar
Justin Sheehy wrote
Sorry for the double-post, that was not intended. What about setting DW=DR=2? In this case only at most one partition can succeed at writing, and the partition that fails to durably write the value would be interpreted as 'failed', and one could simply retry a bit later. What do you think?

Kaspar
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Kresten Krab Thorup
Kaspar,

When a Riak write "fails" the value can still have been written.

Failure is really just a notification that the write didn't complete as requested, usually because one or more of the cluster writes failed.

And being written, even just to a single node, that singly written value can later be read and supersede earlier (successfully) written ones.

Kresten


On Jan 7, 2013, at 2:44 PM, qaspar <[hidden email]<mailto:[hidden email]>> wrote:

Justin Sheehy wrote
Yes, I confirmed this earlier in this thread:

http://lists.basho.com/pipermail/riak-users_lists.basho.com/2013-January/010672.html

-Justin

Sorry for the double-post, that was not intended. What about setting
DW=DR=2? In this case only at most one partition can succeed at writing, and
the partition that fails to durably write the value would be interpreted as
'failed', and one could simply retry a bit later. What do you think?

Kaspar




--
View this message in context: http://riak-users.197444.n3.nabble.com/Atomicity-of-if-not-modified-tp4026430p4026482.html
Sent from the Riak Users mailing list archive at Nabble.com<http://Nabble.com>.

_______________________________________________
riak-users mailing list
[hidden email]<mailto:[hidden email]>
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com



Mobile: + 45 2343 4626 | Skype: krestenkrabthorup | Twitter: @drkrab
Trifork A/S  |  Margrethepladsen 4  | DK- 8000 Aarhus C |  Phone : +45 8732 8787  |  www.trifork.com<http://www.trifork.com>





_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

qaspar
Kresten Krab Thorup wrote
When a Riak write "fails" the value can still have been written.

Failure is really just a notification that the write didn't complete as requested, usually because one or more of the cluster writes failed.
Can you post a link that confirms this when DW (on top of R) is set to 2 and N=3?

Kaspar
Reply | Threaded
Open this post in threaded view
|

Re: Atomicity of if_not_modified?

Les Mikesell
On Wed, Jan 9, 2013 at 10:33 AM, qaspar <[hidden email]> wrote:

>> When a Riak write "fails" the value can still have been written.
>>
>> Failure is really just a notification that the write didn't complete as
>> requested, usually because one or more of the cluster writes failed.
>
> Can you post a link that confirms this when DW (on top of R) is set to 2 and
> N=3?

Do the initial reads to pick up the vector clock need to see a quorum
before any writes happen here?   I suppose you could still have a
scenario where the partitioning happens between these steps.

--
   Les Mikesell
     [hidden email]

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com