<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 15, 2013 at 10:44 PM, Ludovic Demblans <span dir="ltr"><<a href="mailto:ludovic@demblans.com" target="_blank">ludovic@demblans.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":aq" style="overflow:hidden">Hi Jesper, i don't really understand why you advise me to use a very<br>
fast DB, (like voltDB) because your previous point was that if things<br>
are kept in state, storing it to the database should only be done from<br>
time to time (like just after killing a big boss).<br>
<br>
I want my models transient (even implemented as regular gen_servers),<br>
but i don't want to brutal-kill them : I just ask them gently to<br>
terminate and to store their data before. So they have time to do so.</div></blockquote></div><br>I am just trying to say that this model will scale quite well. Since you will have relatively few write-backs to stable storage. Also note you will have very few reads compared to writes in this model. So write-centric database systems can also do well in this scheme. Cassandra comes to mind, but I don't like it too much.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I would probably just have a timeout on the gen_servers and if they are not being used for some grace-period, they write their state back onto stable storage and terminates. If a player then comes back, you can rejuvenate the process. Eventually by replaying all moves from the start. This means the capacity of the machine is limited by number of players currently playing, which is probably a much lower number than the amount of players in the database systems.</div>

<div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br>J.
</div></div>