Question

Scenario: Apache Wicket based web application running on Tomcat server.

User opens URL in browser, session is created and simple main page is shown in browser, user clicks on button and AJAX call is invoked. Application gets request and doing some stuff preparing response. In same time user or JavaScript in browser invokes another AJAX call -- this second requests is processed in another thread in application, and because most parts of application are session specific and aren t thread-safe (because one user = one session), exception throws.

Possible solutions:

make all application classes thread-safe (very costly)
adapt GUI so no simultaneously runs two AJAX calls in one session (not possible due nature of browser GUI)
synchronize all requests in one session on Wicket or Tomcat level (but how?)
another practice or technique ???

Thanks

Answer 1

Requests to pages or components within the same PageMap in a single Session are already synchronous - only one thread at a time. Requests for resources like images, javascript, css files etc. are handled asynchronously. (Different clients never block each other as each client has its own Session and PageMap).

However, access to items in the Session itself, I believe, are not explicitly synchronized.

Incidentally, accessing the Session/Pages from a thread which is not a Request Thread is not a good idea, as the container is free to do anything with your Session/Page between requests - e.g. write it out to disk etc.

Answer 2

What is the exception that is thrown? If an exception is thrown then I would assume that there is a critical section of the Session object that needs to be synchronized or handled with more care and maybe not the entire session.

I have not had reason to utilize them much, but I know there are channels as part of the wicket-ajax.js (found in org.apache.wicket.ajax package). These control how multiple AJAX calls are handled. They might be worth a look. In this file is the following comment:

/**
 * Channel management
 *
 * Wicket Ajax requests are organized in channels. A channel maintain the order of 
 * requests and determines, what should happen when a request is fired while another 
 * one is being processed. The default behavior (stack) puts the all subsequent requests 
 * in a queue, while the drop behavior limits queue size to one, so only the most
 * recent of subsequent requests is executed.
 * The name of channel determines the policy. E.g. channel with name foochannel|s is 
 * a stack channel, while barchannel|d is a drop channel.
 *
 * The Channel class is supposed to be used through the ChannelManager.
 */

友情链接