3

The default mode of google appengine is that each instance runs in single threaded mode. They handle concurrent requests by spawning new JVM instances if it is required.

A new switch though allows appengine to handle multiple requests in parallel on the same instance.

What I've been doing so far in regularly hosted Java web applications in order to ensure thread safety between requests of the same user was to synchronize on the http session (or on a value stored in the session). Spring does it as well (using the synchronizeOnSession flag).

This is not possible in GAE because the HttpSession (together with all variables it stores) is always new in each http request. That is, the hashcode is always different. So synchronizing on that has no effect whatsoever. But even if this was possible, appengine does not guarantee that two requests from the same user will be handled by the same instance (something like sticky session).

The new flag of appengine warns that:

If you wish to use concurrent requests, your application code needs to use proper thread synchronization before you enable .

So, how can I ensure that my application will be thread safe regarding operations from the same user? I'm mostly concerned on actions that the user can perform on data existing in his http session. I obviously only care about synchronizing requests of the same user in the same instance.

Thanks

cherouvim
  • 31,725
  • 15
  • 104
  • 153
  • What are you trying to achieve? Without shared state, there's no need to synchronize. Are you concerned about concurrent updates to the session? What sort of updates are of concern? – Nick Johnson Jun 14 '11 at 01:23
  • I'm concerned about http://www.ibm.com/developerworks/java/library/j-jtp09238/index.html which in self hosted apps I've been always fixing using the per-user request processing serialization trick. So yes, I do have some plain java.util data structures in the user's session which I update based on user actions. – cherouvim Jun 14 '11 at 04:28
  • What are you storing in the session? Is it something you could/should be storing in the datastore instead? – Nick Johnson Jun 14 '11 at 05:13
  • I see your point. If I only store the user id in the http session and keep fetching the user's data from the datastore in each request then it'll be safe, right? – cherouvim Jun 14 '11 at 05:37
  • Right, as long as you use datastore transactions where appropriate. It may be that you can provide a better experience if most of your data is user-scoped rather than session-scoped, too - see Amazon's (very) persistent shopping baskets as an example. – Nick Johnson Jun 14 '11 at 06:04

1 Answers1

2

A few notes:

  1. Try keeping application state on client side, i.e. handle it with javascript. There you can prevent user to send multiple requests at a time or out-of-order.

  2. Since GAE can run several instances in parallel on different servers, your effort to synchronize on session will work most of the time, but is not guaranteed to work all of the time.

  3. I suppose what you are trying to do is prevent user to put his data in inconsistent state (by executing actions out-of-order). Ultimately the only point of sync in GAE is Datastore transactions. Use them to keep data in consistent state.

Peter Knego
  • 79,991
  • 11
  • 123
  • 154