UNICOM® Digital Transformation Toolkit (UDTT™) 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:
▪ Pending: While a request is in process, another request comes in with the same key
▪ Inconsistent: While a request is in process, another request comes in with a key equal in all but the event name
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:
▪ Aging: A request with a key equal to the previous request, or with a key equal in all but the event name to the previous request, comes in too close to the time of the previous request (in a timeframe not allowed by the application)
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:
▪ minRequestSubmitTime: Value in seconds. The default is 0. To prevent another request being processed within a certain time after the first request, change this value. For example, if this value is set to 3, a second request coming within 3 seconds of the first request will not be processed.
▪ doubleClickMessage: A request that is received while another request coming from the same page and within the same session is being processed will be considered a double click. The second request will be discarded. By default, the following message will be displayed:
▪ The following request has been received while another request coming from the same page and within the same session is being processed. This request has been considered a double click.
▪ inconsistentProcessorMessage: Two concurrent requests that come from the same source and ask for different processor events will be considered a double click. The second request will be discarded. By default, the following message will be displayed:
▪ Two concurrent requests coming from same source asking for different processor events have been detected, second request has been discarded.
▪ agingMessage: This item will only become active if minRequestSubmitTime is changed to a value greater than 0. A request that is received less than minRequestSubmitTime after another request coming from the same page and within the same session will be considered a double click. The second request will be discarded. By default, the following message will be displayed:
▪ The following request has been received only a short time after another one coming from the same page and within the same session has been processed. This request has been considered a double click
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.