struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nilan Shakya <nsha...@mortgagehub.com>
Subject RE: Problem with form submission
Date Wed, 10 Jul 2002 16:00:49 GMT
Thank you James.

I am still not sure where to put saveToken(request) and
isTokenValid(request, true) is not taking. It is not accepting as valid
method. 

I am hoping that you will give me some clue for that.

Thank you,
Nilan

-----Original Message-----
From: James Mitchell [mailto:jmitchtx@telocity.com] 
Sent: Wednesday, July 10, 2002 12:58 AM
To: Struts Users Mailing List
Subject: RE: Problem with form submission,

I saved the below msg because this is a very common question:

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Friday, June 28, 2002 3:10 PM
> To: Struts Users Mailing List
> Cc: Ivan D. Sager
> Subject: Re: mapping
>

<snip/>

>
> To deal with resubmits, the most important issue is to avoid updating the
> database twice when the user accidentally resubmits the same form.  Struts
> has a feature called "transaction control tokens" that help you avoid
> this, which is very simply used as follows:
>
> * In the Action that sets up your input form (i.e. before you forward
>   to it), execute the following
>
>     saveToken(request)
>
>   to save a special value in the user's session that will be used in
>   the next step.
>
> * In the Action that receives the form and updates the database, add
>   the following logic before you do the update:
>
>     if (isTokenValid(request, true)) {
>       ... this is a resubmit, so go display an error ...
>     }
>
>   The "true" parameter causes the token to be removed from the session
>   so that it doesn't interfere with subsequent form submits.
>
> This way, the submit will work the first time, but fail on any accidental
> or on-purpose resubmit, and you avoid adding the information to the
> database twice.  It also prevents the user from navigating directly to the
> "myDB.do" URL without going through your normal setup actions -- because
> the transaction token would not have been placed in the session, so the
> isTokenValid() test would fail.
>
> Craig
>
>



James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta




> -----Original Message-----
> From: Nilan Shakya [mailto:nshakya@mortgagehub.com]
> Sent: Tuesday, July 09, 2002 6:59 PM
> To: 'Struts Users Mailing List'
> Subject: Problem with form submission
>
>
> Hi All!
>
> I am having a problem while submitting a form. My form submission
> sometimes
> takes delay because it has to do lots of validation before updating the
> information in database. While the form is on the process of submission of
> data if I click the same submit button once again it is
> submitting the data
> once again. This means that, now my output listing of items from db shows
> repeated data set submitted (same data set submitted twice). I want to
> prevent the form be submitted once it is on the process of submission of
> data (disable the submission of form if it is already on the way to submit
> something).
>
> Does anyone have any idea to solve my problem?
>
> Your help will be greatly appreciated.
>
> Nilan
>
>
>
> -----Original Message-----
> From: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
> Sent: Tuesday, July 09, 2002 11:39 AM
> To: Struts Users Mailing List
> Subject: Re: Off-Topic: JMS Design Question...
>
>
>
> To begin with, I'd recommend using a web service instead of  just
> JMS. It's
> more reusable, has the ability for a variety of clients to access it and
> comes with fewer networking headaches. Plus they are especially good for
> sending XML. Given the fact that you are simply sending messages and
> getting responses, this may be better.
>
> But I've also built JMS apps as well. JMS is extremely cool and
> has a whole
> bunch of functionality that might be useful.  In fact, this is
> how Weblogic
> implements message-oriented web services (see - "Message-Style
> Web Services
> and JMS" at
> http://edocs.bea.com/wls/docs61/webServices/develop.html#1031913 ).
>
> Using JMS within your container with SOAP as the transport protocol as
> outlined in the weblogic links above would be a great solution. It gives
> you persistence within your container and theirs, while exposing
> the app as
> a web service.
>
> I believe this simplifies your solution:
>
>  - Your web app either:
>       1.          - Puts the transaction into a JMS queue (topic or
> point-to-point) on your machine
>             - Another process on your machine gets  the message and then
> makes a message-based web service call to their app server
>             - Their app server (which is exposed as a web
> service) gets the
> message, processes it and places the result on an outoging queue
>             - Your web sevice call then retrieves the results.
>       or, 2.      - Your web app simply acts as a client to their web
> service and sends the message/retrieves the results by itself.
>             - In this case you may be able to use the simpler, RPC-style
> web service.
>             - In this case you also lose the ability to easily persist the
> transaction for sending later it their service is unavailable.
>
>
> Let's assume you choose option #1 above -  to answer your questions:
>
> 1)  If Client's App Server is down, then our MDB should keep resending
> till the message is sent successfully.  How can I do this in JMS?
>
>  - roll-back your read of your internal JMS queue. The message will be
> there when you retry at some later time. The normal transaction management
> stuff in your app server should handle all this.
>
>
> 2)  If our JMS Server is down (shouldn't happen, but let's say it does)
> what should the Web App do?  Would "Durable Subscriptions" help in this
> case?
>
>  - Log the information you captured in a database and/or via an e-mail
> message to someone who cares and intervene manually (uless you want to
> write some fail-safe backup delivery - but then how do you provide back-up
> in case the back-up fails?). "Durable Subscriptions" would allow
> you to not
> lose any messages already on the queue, but wouldn't help you add new
> transactions if they came along while JMS was down.
>
> Since this is off-topid. feel free to respond to me directly if
> you want to
> follow up.
>
> Kevin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hello,
>
> This is kind of off-topic, so I apologize in advance.  We do have some
> J2EE gurus on this mailing list so I decided to ask it here.  (Is there
> any other *active* mailing list where I can post JMS related questions?)
>
> Anyway, I need some help to develop a JMS based solution. Here's what we
> are trying to accomplish;
>
> We need to send XML messages (as well as other types of messages) back &
> forth between two Application Servers. In other words, a Web Application
> created by us will send a message to the application server of our
> client and vice versa.
>
> This is what I was thinking of doing;
>
> 1) When it's time to send a message on our side, we will write it to a
> Topic in our App Server.
> 2) A MDB on our side will retrieve the message and send it to the Topic
> of our client.
>
> The same logic will apply for incoming messages;
> 1) Client will write a message to our Topic.
> 2) A MDB on our side will then pick up this message and process it.
>
> If this sounds okay, then I am wondering how I can handle Exception
> conditions.  For example;
>
> 1)  If Client's App Server is down, then our MDB should keep resending
> till the message is sent successfully.  How can I do this in JMS?
> 2)  If our JMS Server is down (shouldn't happen, but let's say it does)
> what should the Web App do?  Would "Durable Subscriptions" help in this
> case?
>
> I would greatly appreciate any input in this matter. Thanks (a lot) for
> your time.
>
> - Ajay
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>



--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message