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]>
