I doesn't actually sound like you need strong consistency at all.
Strong consistency can be set at a bucket-type level, and will get you
what you want, but it may be too heavy handed.

It sounds like the token should be written to Riak and you should be
getting a durable ack from Riak before ever granting the client to the
session. Given this, the "tunable CAP" controls in Riak may help you.

There is more on this here in these blog posts:
http://basho.com/posts/technical/understanding-riaks-configurable-behaviors-part-1/
http://basho.com/posts/technical/riaks-config-behaviors-part-2/
http://basho.com/posts/technical/riaks-config-behaviors-part-3/
http://basho.com/posts/technical/riaks-config-behaviors-part-4/
and this doc:
http://docs.basho.com/riak/2.0.0/dev/advanced/cap-controls/

You probably want to do:
n=3
pw=quorum
pr=quorum
notfound_ok=false
----

I might argue that this might be too heavy-handed, but I recommend
reading the above posts for a better understanding of the consistency,
and availability guarantees Riak can provide. At the end of the day,
you're trading off (availability, performance) vs. consistency.

On Fri, Jun 19, 2015 at 12:48 AM, Cosmin Marginean <cosmin...@gmail.com> wrote:
> Hi Ilya
>
> Read “quorum” is unusual and a bit against the idea of distributed DB, but I
> believe what you might find useful is enabling strong consistency, which you
> can then chose to apply at a bucket(type) level:
> * http://docs.basho.com/riak/latest/dev/advanced/strong-consistency/
>
> One of the reasons we chose Riak is precisely the fact that you can silo
> your data into “consistent” and “available” within the same cluster. An
> important thing to remember is that with strong consistency enabled you will
> need a minimum of 3 nodes (yes, for your dev environment too), otherwise
> writes to strong-consistent buckets will fail.
>
> Another relevant note here about strong consistency in Riak (and distributed
> DB in general): is not so much about the performance impact, but more about
> sacrificing availability to achieve this.
> (The C vs A in the CAP theorem, if we are to oversimplify this)
>
> Regards
> Cos
>
> On Friday, 19 June 2015 at 01:12, Ilya Kutukov wrote:
>
> Hi!
>
> I am planning to maintain session storage over Riak KV.
>
> Core case: when user is signing in to the service session token with some
> meta is returning to the client and then saving for further usage. At the
> back-end side this session key is placing to the session storage.
>
> Riak could response false "not found" when user is providing client-side
> token on next request, what following instantly after the session record is
> placed to Riak.
>
> From the end-user POV you log in, than you surprisingly not logged in, then
> you are refreshing/restarting client and everything is back to normal. Bad
> glitchy case.
>
> Riak have typical distributed DB problems when you are reading after write
> instantly. Also there is a high consistency mode with performance
> trade-offs.
>
> Is it possible to configure or modify Riak cluster to act hybrid way:
>
> Normally cluster is working in HA mode. E.g. on secondary index searches,
> updates, deletions of the existing keys.
>
> But when you are directly asking for the key that seems to be missing the
> full quorum is required to claim that there is really no such key on all
> nodes in according partition to say "No". Any other case is "Yes" after long
> or a short delay.
> In theory, such behaviour will make deletion of keys slower, but situation
> with false "not found" will be better.
>
> Or i'm missing some obvious way to resolve read-after-write problem like
> proxying requests to the session storage through the single instance 3-rd
> party cache?
>
>
> --
> Best regards,
> Ilya Kutukov
>
> +7 962 909 10 35
> post.i...@gmail.com
> skype: blinkedeye
> _______________________________________________
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
>
> _______________________________________________
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>

_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to