On Tue, 2003-10-28 at 23:40, Adam Hardy wrote:
> I don't store the token in the session. When the form submits, I check
> the session for a hashmap, & if the token is not in the hashmap, I allow
> the transaction and then put the token in the hashmap.
Interesting. You store the successful token
ppservers, clustering, client types, etc.
;)
justin
> -Original Message-
> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 28, 2003 6:34 PM
> To: Tomcat Users List
> Subject: Re: Session exclusivity (was Form Double Submit Detection)
>
Tomcat Users List
> Subject: Re: Session exclusivity (was Form Double Submit Detection)
>
>
> So, it looks like the Catalina folks feel like the session is okay to
> synchronize on, but I agree that one shouldn't bet
Ralph,
BTW: In my version of tomcat (4.0.3) jasper generates
code for the jsp's that synchronizes on the session
to access session attributes. Is the current version
doing the same ?
I'm using 4.1.27 and yes, is does synchronize on the session object that
it gets (I'm only including the relevant
--Original Message-
> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 28, 2003 5:37 PM
> To: Tomcat Users List
> Subject: Session exclusivity (was Form Double Submit Detection)
>
> Well, not always. Because of threading and memory issues with
> the
Ralph,
Does that mean that you
can never have exclusive access to your own session?
Yes you can, but the only safe way is to synchronize
on an object inside the session, not the session itself.
Well, not always. Because of threading and memory issues with the JVM,
one thread might put something
chultz [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 28, 2003 11:56 AM
> To: Tomcat Users List
> Subject: Re: Form Double Submit Detection
>
>
> without ever giving it much thought. Does that mean that you
> can never have exclusive
Justin,
Agreed. One word of caution...
>
We actually synchronized on the session...
You aren't guaranteed to have the same HttpSession object for every
request -- HttpSession is an interface which is implemented internally
and wrapped by a facade. Synchronizing on the actual object you get
fr
On 10/28/2003 10:42 AM Walker Chris wrote:
Tom,
You can also put JavaScript code in the form's onSubmit event code to
disable all the elements in the form. To make sure this happens after
submission (otherwise nothing gets submitted) use window.setTimeout() to run
the disable script after a short
--
From: Bill Lunnon [mailto:[EMAIL PROTECTED]
Sent: 27 October 2003 23:26
To: Tomcat Users List
Subject: RE: Form Double Submit Detection
Tom,
Don't know if this is complimentary to your workflow,
try a javascript confirm (ie a client side pop-up, asking the user to click
"Ok" to co
On Tue, 2003-10-28 at 15:49, Justin Ruthenbeck wrote:
> Here's the situation (correct me if I'm wrong):
>+ User fills out a form and clicks submit
>+ The browser submits the form and sits in a wait state
>+ The server begins processing a request for a new record
>+ The user clicks
Agreed. One word of caution...
At 06:46 PM 10/27/2003, you wrote:
I've had to do this before when credit card processing was being done. A
double-click can result in the credit card being charged twice, so
you've really got to avoid it.
We actually synchronized on the session for the duration
At 06:02 PM 10/27/2003, you wrote:
On Tue, 2003-10-28 at 14:18, Justin Ruthenbeck wrote:
> At 04:20 PM 10/27/2003, you wrote:
> >On Tue, 2003-10-28 at 12:51, Justin Ruthenbeck wrote:
> >
> > > Server side, instead of putting a token in the session when the
page
> > is
> > > *served*, put a token i
Tom,
> Don't know if this is complimentary to your workflow,
> try a javascript confirm (ie a client side pop-up, asking the user
to click
> "Ok" to continue). This will catch any double clicks on the client
side.
Unfortunatly I think our users would object to this solution.
Server side, inst
On Tue, 2003-10-28 at 14:18, Justin Ruthenbeck wrote:
> At 04:20 PM 10/27/2003, you wrote:
> >On Tue, 2003-10-28 at 12:51, Justin Ruthenbeck wrote:
> >
> > > Server side, instead of putting a token in the session when the page
> > is
> > > *served*, put a token in the session while the submission
At 04:20 PM 10/27/2003, you wrote:
On Tue, 2003-10-28 at 12:51, Justin Ruthenbeck wrote:
> Server side, instead of putting a token in the session when the page
is
> *served*, put a token in the session while the submission is being
> processed (use it like a semaphore). The token has a finite li
On Tue, 2003-10-28 at 12:51, Justin Ruthenbeck wrote:
> Server side, instead of putting a token in the session when the page is
> *served*, put a token in the session while the submission is being
> processed (use it like a semaphore). The token has a finite lifecycle
> (created on form submis
At 03:34 PM 10/27/2003, you wrote:
On Tue, 2003-10-28 at 12:26, Bill Lunnon wrote:
> Don't know if this is complimentary to your workflow,
> try a javascript confirm (ie a client side pop-up, asking the user to
click
> "Ok" to continue). This will catch any double clicks on the client
side.
Unf
On Tue, 2003-10-28 at 12:26, Bill Lunnon wrote:
> Don't know if this is complimentary to your workflow,
> try a javascript confirm (ie a client side pop-up, asking the user to click
> "Ok" to continue). This will catch any double clicks on the client side.
Unfortunatly I think our users would obj
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, 28 October 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Form Double Submit Detection
I've designed my workflows so that they do not need to store anything in
the user's session. This allows the user to conduct more than one
instance of a particular task
I've designed my workflows so that they do not need to store anything in
the user's session. This allows the user to conduct more than one
instance of a particular task at the same time without data getting
mixed up. However this presents me with a problem if the user double
clicks the submit butto
21 matches
Mail list logo
