wood burning stoves 2.0*
The moose likes Struts and the fly likes Returning Previous Response Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Returning Previous Response" Watch "Returning Previous Response" New topic
Author

Returning Previous Response

Mark Newton
Ranch Hand

Joined: Jan 31, 2006
Posts: 129
Hi,

I'm pretty sure that this is a dumb question, but I've been Googling around for a while, and can't think what to search for...

Basically, I'm working on a Struts Interceptor, for handling multiple submits. I'm using the Synchronizer Token design pattern; saving a simple number on the client page, and in the session. Upon the submit I check that the numbers match, and, if so, increment the number in the session. Then I have a custom tag which gets that incremented number when it renders the next JSP page. The predictability of simply incrementing numbers has been considered, and is not a problem for us.

I think (hope) that's all sensible, and is well documented in various places talking about the Synchronizer Token pattern. What I'm stuck on is how to handle the case when the values don't match. I want to store the response that was sent back the first time, and, upon hitting the interceptor with a previous 'token', pull out that response and re-send it, without needing to go any further into my application. My question is simply: where and how do I store that response.

I'm pretty new to Servlets (and JEE in general), but have a few years of core Java, and JSE experience. Can I just keep a map somewhere with key=value of token=response? Is that safe for threads / multiple servers / etc, etc? If not - what's better?!
Ashok Kumar Babu
Ranch Hand

Joined: Jul 25, 2006
Posts: 129
Can I just keep a map somewhere with key=value of token=response? Is that safe for threads / multiple servers / etc, etc? If not - what's better?!


Creating the dynamic response from the servlet itself.


Ashok<br /> <br />SCJP 91%<br />SCWCD 88%
Mark Newton
Ranch Hand

Joined: Jan 31, 2006
Posts: 129
Thanks Ashok, but sorry, I don't fully understand your response. Do you mean to just repeat the same functionality that was used for the original request? That's what we're trying to avoid really - if we've already generated the response, we want to just return it from the interceptor, without having to go any further.

Sorry if I mis-understood what you meant!
Vilmantas Baranauskas
Ranch Hand

Joined: Dec 20, 2006
Posts: 89
Independently from where you store you have some questions to answer:
- How big will be the response.
- How many responses there will be per second.
- For how long will you store the response.

If you still want to store complete response, then you may implement javax.servlet.Filter. I think this is the best place to do such request/response caching.


Author of <a href="http://www.newsinjector.com" target="_blank" rel="nofollow">NewsInjector</a>
Vilmantas Baranauskas
Ranch Hand

Joined: Dec 20, 2006
Posts: 89
BTW, you can eliminate 99% of double submits by this simple JavaScript on client side.

 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Returning Previous Response
 
Similar Threads
Synchronizer Token: for the J2EE pattern book authors ...
Session expire problem with HttpSessionListener
Duplicate form submission - Synchronizer Token Pattern
Returning Previous Response
Action resubmitted with browser's back button