IBM WebSphere Multichannel Bank Transformation Toolkit, Version 7.1

Duplicate request handling

The Bank Transformation Toolkit provides a mechanism to handle the problem of duplicate requests from HTML clients. A duplicate request occurs when a user clicks on a link that sends a request to perform an operation, and, before receiving the response, clicks again on the same link. The server receives and processes both requests, leading to the user sending the same request twice (or more times). This can cause inconsistencies in the application, or, even worse, problems like duplicating a critical transaction on the server side.

To handle this problem, the toolkit internally creates a key to identify each request. This key is a concatenation of the following values: sessionId + pageId + operation/processor name. If the request is intended to run a processor instead of an operation, the requested event name is chained at the end to create the key. This key uniquely identifies each request.

The toolkit considers a request to be a duplicate request under either of the following circumstances:

The second point covers the situation where a user clicks different links, all of them on the same page and referring to the same processor, but asking for different events of that processor (for example, on a menu).

In either of these cases, the toolkit will execute the first request normally, discarding the second (and third, fourth, and so on). The error information field of the operation's context ("dse_ErrorMessages" field) will be updated with information about what happened. The error messages that will be added to the error information can be customized through btt.xml. Only the first request is therefore executed on the server, and the user receives the page corresponding to that request. If the page has been set up to do so, it can show the explicit error information and warn the user about what happened.

To give more control to the application designer, there is another parameter that controls this behaviour. While a request is being processed, some information about it is stored, including the operation context and the key described above. Once the request has been processed, this information is deleted. The application designer might decide that the application should not allow requests for that session and page to be processed for a specific amount of time. So, for instance, if it is not reasonable after processing a request to process another request from the same session and page within three seconds, the application can keep the information for the request in memory during those three seconds. This will stop further requests with the same key from being processed during that time. The toolkit therefore also considers a request to be a duplicate request in the following case:

This situation is treated the same as the first two. The result of the first request will be posted to the client, and the error information field of the operation's context will be updated.

You can configure the following four items in the btt.xml file:
These items are found under the "HTML client" keyed Collection in btt.xml. The following is an example where the minimum resubmit time has been set to 3 seconds and the messages have been customized:
<kColl id="HTMLClient">
  <field id="minRequestResubmitTime"
         value="3"/>
  <field id="doubleClickMessage" 
         value="The second request you made is considered a double click 
                and has been discarded."/>
  <field id="inconsistentProcessorMessage" 
         value="Please don't click on a second link until you have 
                received a reply to the first one."/>
  <field id="agingMessage" 
         value="You must wait more than 3 seconds before repeating a 
                request."/>
</kColl>

In order to make this process thread-safe, the processing of requests is session-synchronized, meaning that there will not be two concurrent requests for the same session running. They will all run, but sequentially.



Feedback