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:
- 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.