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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
