This is unlikely to work. You will need to transactionally update each game session entity every 0.5 second. You might get that kind of throughput, but with collisions you may not. The docs officially say don't expect more than 1 write per second per entity group.
Memcache can flush at any moment, so you cannot use it as an authoritative source of game state. You can't use it as a cache of game state either because there is no way to transactionally link it to the datastore - and you will have major contention issues. If you want a game architecture like this, you should use a Backend that periodically checkpoints its state to the datastore. Honestly, you'll have a lot easier time building your system on a different platform with MongoDB (or one of the other high-throughput datastores). Jeff On Thu, May 26, 2011 at 1:08 PM, Rohan Chandiramani <[email protected]> wrote: > Alright, let's give a concrete example. > I'm still working on my game application. > Each gamesession holds 4 players and each player updates the shared > gamession entity once every 2 sec. > Basically every time a player requests the gamesession entity, he/she needs > the most up2date entity. > I don't quite understand what you mean with the durability of writes, as > English is not my primary language. > > Do you mean with durability the amount of time the entity lives in the > memcache? > In that case: the entity should stay alive for no less then 6 minutes, after > 6 minutes it'l be deleted from the datastore anyway. > > If you meant durability as in the likely hood of the request failing to > update in memcache? > That would be catastrophic i guess(however a few lines of could should > change that). > Now in the case of delaying writes to the datastore(with a Task Queue i > presume?) > A risk would be that: > > Player0 sends an update. > Memcache is updated. > Task is made. > Memcache entity bites the dust. > Player1 asks for an update. > Memcache picks up the entity in the datastore, wich hasn't been adjusted yet > from the task. > Player1 gets an old update, and there is an temporary desync in the client. > Now that would be an unwanted but tolerable situation. > I guess it all comes down to, how long my entity will live in memcache. > And as i've read the docs, memcache is unreliable. > Yet is this unreliability after some amount of time or could an entity get > lost after 0:05 seconds of creation(so to speak). > Maybe even more important, what kind of error margin would i be looking at. > After reading this, could you conclude anything about whether to use > memcache in my case? > I'm guessing delaying writes would not be a smart option in my case? > > I hope my story is understandable. > Much appreciated, > Rohan > > > > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
