-------- Original Message --------
Subject: Transaction Token & long running process ...
Date: Thu, 20 Feb 2003 08:45:44 +0100
From: "Hossfeld, Frank" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>

Hi Ted,

I read the answer you wrote Greg Hess. And because I can't answer in the
list - don't know why - I reply directly. I hope this works.

We are searching for a solution of the same problem. We are using Struts and decided to use the Transaction Token to solve this problem.

This works fine, except of one situation.
Here is the text, I wanted to send to the list yesterday:

> Hi,
> we use the Struts Token solution to resolve the race-condition (which
> results e.g. by double-click).
> Now we have a problem with the sendRedirect(), because a
> sendRedirect() does not send the token in the URL.
> So the next token check failes.
>
> Is there any method or solution to send the token within the URL?
>
> We discovered this problem in the following situation:
>
> Every request in our application does the token-check. So, when we
> change from one action to another by forward-mapping, which is defined
> with 'redirect="true"' in the struts-config, the change > failes,
> because the second request, redirected from the browser, does not
> contain the token.
>
> Regards Frank


Perhaps you can tell me, if we make a mistake or if it is a problem in
Struts.

For long-processing transactions, there are two possible solutions, we
think:

First, the first request writes his message into the session. The second
request, which has to wait until the first gets his SocketException ... :-), reads the message out of the session and presents it, with the response of the second request. This will not always work, because when the second request has another host, the session is not available and the message not reachable. So, the behavior of the application is not always the same.

Second, you can send a "in progress"-page after receiving the first request, after you started the long running process. This page will send every second a request from the brwoser to the server, where the server is able to check if the long running process has finished. When the long running process has finished, you can send back the response containing the messages of the long running process. In this case, you also have the problem, that the User can close the browser, push the cancel-button or change the URL.

In my opinion, the Transaction Token solution is the best one, to solve this problem.

Regards Frank

------------------------------------------------------------------------------
Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene Information nicht rechtsverbindlich. Eine rechtsverbindliche Bestaetigung reichen wir Ihnen gerne auf Anforderung in schriftlicher Form nach. Beachten Sie bitte, dass jede Form der unautorisierten Nutzung, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail nicht gestattet ist.Diese Nachricht ist ausschliesslich fuer den bezeichneten Adressaten oder dessen Vertreter bestimmt. Sollten Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich mit dem Absender der E-Mail in Verbindung zu setzen.
----------------------------
For legal and security reasons the information provided in this e-mail is not legally binding. Upon request we would be pleased to provide you with a legally binding confirmation in written form. Any form of unauthorised use, publication, reproduction, copying or disclosure of the content of this e-mail is not permitted. This message is exclusively for the person addressed or their representative. If you are not the intended recipient of this message and its contents, please notify the sender immediately.

==============================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to