java two request/thread that interact on the same session

[Davide Montesin]

Hi,

I like to develop a Rich User Interface. To obtain this on user interaction I need two thread: one for action processing,
and one for incrementally update the client side (html).
I generate two http requests from the client. The two request must communicate.
The "update" request must exchange data with the "action" request. Both request have the same
session id.

Can I use the session for exchanging data between two thread? Or can be that at the same time
exists more than one node/jvm that is elaborating the same session id? If yes, data in session
is synchronized in realtime?

What about synchronizing the two request. Can I use the Thread.wait/notify or no because
request for the same session can be on different nodes?

Must I poll the session from a thread to discover if the other thread has written new information?

Exist another way, i.e. memcache, to obtain this in google app engine.

Thanks in advance for any help!

[Michael Hermus]

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

[Davide]

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?

--
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/-/Y_5YcyXW9Z0J.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Davide]

Hi,

is possible that session is not replicated until the end of the http request
is reached? How is possible to replicate DURING the http request?

I am on the wrong way?

[Michael Hermus]

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.

[Michael Hermus]

It is definitely NOT written until the end of the request. You cannot use the session object that way. Memcache would be your best alternative, but it is possible you are attempting to implement a flawed pattern.

[Davide]

Hi Michael,

many thanks for the help! Yes I think I am using the wrong way.

What I need is a long running request "main" that execute some code
server side. At some time the "main" request need client values.
I have thinked to use a second request that take the work to fetch
a client value and once again on a request, it give the value to the
"main" request that then will continue to execute. Because the
"main" request survive more "fetch" requests, the session is not
updated ad expected.

Do you think that channel api can help me for this?

--
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/-/kkGvdz2IcZQJ.

[Michael Hermus]

You should click the link I provided in my first post, and read the doc. The Channel API allows you to create a persistent connection between the server and a JavaScript client, allowing you to send data back and forth. I imagine that would allow you to accomplish your goals.

[Davide]

Hi Michael,

I have clicked on the link you provide and read the documentation. I have created a small
project to test channel api.

I can make it running. From the "main" request I can send a message to the client using the channel.
The client can then respond to me. But I have seen that the response is not synchronous,
it can be done using POST (or GET). This mean that the "client value" is owned by a second
request that need to give this value to the "main" request.

So the problem is not far different with channel api.

Looking at the java-channel-tic-tac-toe example I have seen that the MoveServlet load
a Game object from the datastore (not session), make the move and inform other clients.

In this case is the datastore the communication channel... And this can I use
even in my solution.

I will investigate more the problem. Firs I check if the channel api can be mixed with session,
or to use datastore as communication channel.

Many thanks!

[Michael Hermus]

Yes, the channel itself is one way from server to client, while the client to server communication is via normal HTTP requests.

You seem to be stuck on the pattern of having two threads on the server side that need to interact directly with each other. I don't think that is correct. Your application state should be stored in the Datastore. Your 'update' requests can perform whatever processing they need to and interact with your application state, and then send results back to the client. You can use either the Channel API or a simple AJAX pattern to create a rich user interface in this way.

Best of luck.