How to avoid muti-committing a form inSTRUTS?

[rayzyang]

as the topic.I built a user-registering system by struts.For
optimizing,I need to add a usage that can avoid commit the register
form for muti times.I knew a little about the Token class ,and
actually used it ,sadly,I failed.I hope I can find help here for
resolving my problem.Thanks!

 

[Lew]

as the topic.I built a user-registering system by struts.For
optimizing,I need to add a usage that can avoid commit the register
form for muti times.I knew a little about the Token class ,and
actually used it ,sadly,I failed.I hope I can find help here for
resolving my problem.Thanks!

I don't know what the Token class is, but the standard technique to handle
reposts is called sometimes the "Token Pattern". The name comes not from a
class "Token" but from an arbitrary object, often a String, used as a token, a
marker for something.

The defense against applying the same transaction multiple times is to enforce
"idempotency" - the property that a transaction only has effect the first time
it's applied.

In the case of a form POST, you place a token, let's say a string with the
name of the form, in the session the first time you generate the page. In the
handler for the form submit, check for the token, that is, the string with the
identifier of the form (could also be a GUID like a hexadecimal string) in the
session.

String token = (String) session.getAttribute( "token" );

If the token is in the session the handler is allowed to apply the
transaction. First, it must remove the token

session.removeAttribute( "token" );

then perform the business logic.

If the handler is invoked again before a new page is generated, the check for
the token in the session will return null. In that case do not perform the
business logic. That way the handler only performs business logic once per
screen no matter how many times the same submit hits it.

Your logic is then "idempotent".

GIYF.
So is Wikipedia.
<http://en.wikipedia.org/wiki/Idempotence_(computer_science)>

-- Lew

 

[rayzyang]

I don't know what the Token class is, but the standard technique to handle
reposts is called sometimes the "Token Pattern". The name comes not from a
class "Token" but from an arbitrary object, often a String, used as a token, a
marker for something.

The defense against applying the same transaction multiple times is to enforce
"idempotency" - the property that a transaction only has effect the first time
it's applied.

In the case of a form POST, you place a token, let's say a string with the
name of the form, in the session the first time you generate the page. In the
handler for the form submit, check for the token, that is, the string with the
identifier of the form (could also be a GUID like a hexadecimal string) in the
session.

String token = (String) session.getAttribute( "token" );

If the token is in the session the handler is allowed to apply the
transaction. First, it must remove the token

session.removeAttribute( "token" );

then perform the business logic.

If the handler is invoked again before a new page is generated, the check for
the token in the session will return null. In that case do not perform the
business logic. That way the handler only performs business logic once per
screen no matter how many times the same submit hits it.

Your logic is then "idempotent".

GIYF.
So is Wikipedia.
<http://en.wikipedia.org/wiki/Idempotence_(computer_science)>

-- Lew

Lew,
Thanks for replying, how about GET form ?It seems your "Token" doesn't
work....
Struts disposes this problem well with the Action class method
saveToken()\isTokenValid()\resetToken(),and I didn't do well with
it.Is there anything that should be noticed?
(e-mail address removed)

 

[Lew]

Thanks for replying, how about GET form ?It seems your "Token" doesn't
work....

Usually one avoids GETs with Struts applications. In a non-Struts context the
token pattern works just as well with GETs.

Of course, that would be incorrect to do. You are not supposed to use GET for
anything that performs state changes, so there would be no need for
idempotency anyway.

Struts disposes this problem well with the Action class method
saveToken()\isTokenValid()\resetToken(),and I didn't do well with
it.Is there anything that should be noticed?

I am not familiar with these methods. What to their API docs say?

I use session.setAttribute( "token", someObject ) and
session.removeAttribute( "token" ).

-- Lew

 

[rayzyang]

Usually one avoids GETs with Struts applications. In a non-Struts context the
token pattern works just as well with GETs.

Of course, that would be incorrect to do. You are not supposed to use GET for
anything that performs state changes, so there would be no need for
idempotency anyway.


I am not familiar with these methods. What to their API docs say?

I use session.setAttribute( "token", someObject ) and
session.removeAttribute( "token" ).

-- Lew

Your opinion is reasonable,may be the Struts API way doesn't go
well,since I'd never worked out with it yet.

(e-mail address removed)