[google-appengine] Re: Serialised events

2009-08-03 Thread Adam

David, I would suggest using a Request Repeater pattern rather than
Task Queues. What you want to achieve might be difficult or impossible
with Task Queues.

Rather, You can have a request handler, say /processevent, that grabs
an event record from the data store table that holds them, processes
the event and then uses URLFetch to call itself. That gives you single
threadedness.

You can use the event model's __key__ to find the correct event. If
you select 1 record and order on __key__, you'll get the one with the
lowest key, and by definition, that should be the oldest record in the
entity group.

On Aug 3, 6:05 am, David Given  wrote:
> Hi,
>
> I'm trying to write a game using AppEngine. As a result, I need some
> mechanism for running the game AI.
>
> I've considered various architectures and the approach that seems the
> most workable is to have, in the datastore, a priority queue of events
> based on timestamp. I post events to the queue, and then process them in
> order whenever it's necessary to update the state of the game world.
> Most of this isn't hard.
>
> The problem is that I can't find any way of achieving the 'in order'
> part of the problem. It's vitally important that the event processing
> happens serially, or else I'll end up processing events out of order,
> with hilarious consequences --- I would like my unit to pick up cargo
> *before* it departs the current location, thanks very much!
>
> Normally I'd achieve this by having a single thread do all the AI
> processing, so the AI becomes intrinsically serialised. Naturally, this
> isn't possible in AppEngine. The only other approach I can think of is
> to put some kind of big lock around the AI processing routine, to ensure
> that only one thread at a time handles events; but AppEngine doesn't
> have that kind of lock. Transactions aren't suitable because they're not
> blocking.
>
> This must be a situation people have encountered before --- any
> suggestions as to the best way to achieve this sort of thing?
>
> --
> David Given
> d...@cowlark.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---



[google-appengine] Re: Serialised events

2009-08-04 Thread David Given

Adam wrote:
> David, I would suggest using a Request Repeater pattern rather than
> Task Queues. What you want to achieve might be difficult or impossible
> with Task Queues.
>   

That's very cunning --- ta. I can use that.

However, I'm not sure it quite meets all my requirements. This is good 
for ensuring that the event queue gets flushed periodically, which I'm 
going to want to do, but I also want to flush the queue on-demand (so 
that I can quickly process any pending events while the user's actually 
logged in).

Traditionally I'd do this with a big lock around the event processing 
routine, but appengine can't do this. I could use transactions, but I'd 
have to process each event --- which will involve touching and updating 
multiple entities all over my database --- inside a transaction, and 
that's going to be hideously expensive should contention happen (I'll 
end up processing the same event multiple times!) due to the optimistic 
transactions.

There has to be a better way to do this!

-- 
David Given
d...@cowlark.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---