I'll take a look at that. Thank you for the advice.
> Subject: Re: Number of nodes and links
> From: [email protected]
> Date: Sat, 15 May 2010 20:12:26 -0400
> CC: [email protected]; [email protected]
> To: [email protected]
>
> Hi Chris,
>
> Chests in the presumably "Chest" bucket sounds like the container where all
> the contention will take place. What you describe would almost certainly
> require a bucket with allow_mult=true and entail an enormous amount of
> transactional detection within your application and each of your players
> (clients) be uniquely named (X-Riak-ClientId).
>
> What I would do in this scenario is pre-compute all those chest objects (it
> sounds like your'e already doing that) but put them in redis. In fairness, I
> do not know if Riak is where you want to do all that stuff. I would make each
> chest a key in redis as a set containing keys to all the individual items
> within that chest. Just pop the items off the set as requests come in. Redis
> guarantees atomic set operations. Once the client has it's loot key, just
> fetch it out of riak. If you absolutely insisted on using riak here, you
> would probably have to touch the loot item in the loot bucket by locking it
> somehow or flagging it as taken if you weren't confident in your
> transactional/chest locking solution.
>
> I would continue to use riak as your long-term persistent data-store but in
> this specific use case I believe Riak is not the appropriate solution. Also,
> redis would be at least an order of magnitude faster.
>
> -Alexander
>
>
> On May 15, 2010, at 7:33 PM, Chris Hicks wrote:
>
> > First of thank you for the responses.
> >
> > As far as the HTTP interface I don't plan on using that but will be
> > connecting directly through Erlang, so that 8kb limit for that specific
> > case, as far as I understand, won't affect me as much. I would like to get
> > to understand the conflict handling a bit better as in my case I know that
> > this is going to be something I will need to pay particular attention to.
> >
> > I'd like to spell out a scenario that shows how I understand the process to
> > work so that you guys can tell me I have it or I'm totally off base. To
> > start let me say that the project I'm working on is a game, so imagine a
> > chest with a number of items in it which is little more than a chest object
> > with links to the specific items contained in the chest.
> >
> > Player 1, Player 2 and Player 3 all decide to take something from the chest
> > at the exact same time. They all retrieve version 0 (using version for
> > simplicity) of the chest object from the DB. Player 1's
> > connection/processing is lightning fast and they finish, updating the chest
> > document to version 1. Player 2 & 3 finish at the same time and both try to
> > update the chest document in the database, except that it has now changed
> > and so there is a conflict. Now as far as I understand it you can tell the
> > DB to return both versions and let the program handle it. Does that mean
> > that both Player 2 and Player 3 will get version 1 of the document back
> > along with their proposed modified version?
> >
> > If that is the case it seems like I could, if I plan for it from the
> > beginning, simply restart the processing for Player 2 and Player 3 with
> > version 1 acting like the original document. In this way I could make sure
> > that actions taken from a player are done, more-or-less, in a first come
> > first serve basis. If the above is true does it matter how many revisions
> > the document has undergone, as far as what is returned after a conflict?
> >
> > By that I mean what happens if Player 4 tries to get something out of the
> > chest at the same time as the other 3, only for some reason their
> > processing is very very slow and Players 1, 2 and 3 all finish up
> > completely and the chest document is at version 3 when player 4 tries to
> > submit their document back to the D. Does Player 4 get version 3 of the
> > document back along with their own proposed modified document?
> >
> > How close am I as far as how the DB handles this?
> >
> > Hotmail has tools for the New Busy. Search, chat and e-mail from your
> > inbox. Learn more.
>
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
