I suppose you could force the use of multiple instances by setting <threadsafe>false<threadsafe> and using long running requests. Remember, though, the HttpSession state will not be committed to shared state (Memcache and Datastore) until *after *the HTTP request completes. You cannot use the HttpSession object to send data back and forth between long running requests on different machines. You *could *use Memcache for that, I suppose, but I am still not quite clear on your overall architecture. I suggest you check out the channel API and/or other useful patterns for rich client interaction.
On Thursday, May 10, 2012 4:07:25 PM UTC-4, Davide wrote: > > Hi Michael, > > thanks for the reply! > > Is possible to test a case in which two HTTP requests are on different VM? > I like to understand if exchanging info through the session works. > > Must I use synchronized when accessing the HttpSession? > > > On 05/10/2012 03:53 PM, Michael Hermus wrote: > > The two HTTP requests are not guaranteed to execute in the same VM, > regardless of session ID, so you should definitely NOT rely on thread > interaction. The session object is updated in real time, and of course > memcache is a great tool for sharing short lived state, as long as you can > tolerate failures. > > However, it sounds to me like you should really explore the Channel API to > accomplish your goal: > https://developers.google.com/appengine/docs/java/channel/overview > > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/ODL9lP3b6bsJ. 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.
