Hi all, I have a question, and perhaps a request to the Sun serlvet spec leads. First, it is quite common for transactions to take several seconds. For some unknown reason, some of our users don't have a clue that it may take 30 seconds or more for large queries. Even worse, our company doesn't want to post any info on the pages explaining this. So, we often get calls saying how they hit the STOP button of the browser, then submitted the form again, etc..and things didn't work. Sometimes, we even get database resource locks because a request they sent before hitting stop is still running, tying up certain table rows/columns, and submitting the same form tries to access those same rows/columns and can not be accessed at the same time (at least during inserts/updates). So it would seem that there should be some bulit in mechanism of servlet containers to check the session id coming in, and see if any threads exist for that session id already, thus "preventing" this two (or more) requests per user capability. When a user hits STOP, the connection is severed to the server. The server then generates some sort of exception when that request finishes on the server and it tries to send the response back. I'd like to know if anyone has come up with a solution to this problem? It can occur if the user hits STOP then submits, OR if the user opens a NEW window from within the same browser instance, and submits a request (which could be an entirely different link/form, OR the SAME form from a different window as is the case when you open a new window from the File -> New -> Window option if MSIE (and equivalent of other browsers). What I thought of doing is half way there. When a request comes in, store an attribute in the HttpSession that flags a "transaction" (transaction being either a database hit, or just a simple request..period) is activated. This would only work with an MVC framework though..it would require the ControllerServlet to "check" every single request if this attribute existed. If it does, it could simply return a response that indicates a transaction is already in progress and another one can not be started until this one completes. At the end of the ControllerServlet sequence, the attribute would be removed from the session, indicating its done. This would work great for the user that opens a new window from the existing browser, because they would get a response back in the window they opened, and the request that is still going on from the othe window would eventually return the results to that window. Where it doesn't work though is if the user hits STOP, submits the form (or goes to another link and submits from there). The original request would NEVER make it back to the originating window because the user hit the STOP button. In my solution, the user would see the message that a transaction is already in progress, but would never see the results from the original request. I think what should really be done is that Sun and the Servlet spec team enforces servlet containers to handle this for us. But, it would be configurable via the web.xml descriptor. First, I think the servlet engine would have to keep track of each and every thread AND the session that thread is tied to. Then, on each and every request, before creating a NEW thread, it would see if the session id coming in with the thread is already being tied to another thread running. In this case, it would send back a response (of user defined..either jsp page, error message, etc) indicating a transaction is already in progress. Being selectable via a standard approach, the developer/deployer could turn this feature off if not needed. For example, it is often the case an Admin site for employees may allow multiple requests to occur at the same time. Even better, it would be great if there was a way to define "modules" so that a single thread/session per module could be activated, but multiple modules from the same user, same session could be running. Ofcourse, this would require a bit more development requirements for us servlet/jsp developers. Right now, I usually develop under the assumption that only a single thread for any session will run at one time. Therefore, I store non-syncronized objects in that session knowing that concurrency problems shouldn't happen. This is BAD, yes..but it is a very rare chance someone will access (and at that..update..as reading from an object wont create a concurrency exception) the same object from two different threads at the same moment. Keep in mind, its pretty hard for a web browser to do this. The only way it can really happen is if a user hits STOP then submits again, or opens a new window and does it. With all that going, it still will only happen if one requests takes so much time that another request can overlap it from the same user. Anyways... what is the general concensus of JSP/Servlet developers on how to handle this? I can't imagine our site is the only one that has users that hit STOP and resubmit a form. Oh..and we DO use a javascript routine that "checks" for a flag. When a user hits a button to submit, we set a flag. IF they hit the button again, it wont allow them to submit the form. The downside to this is if they hit STOP, then hit submit, the pop-up alert still occurs. They have to refresh the page. There is apparently no hooks into the STOP button of a browser..at least that is MSIE4/Netscape 4 compatible..none that I can find period. But, I would like to get away from using JavaScript..too many damn browser problems. Love to hear feedback on this. Thanks. =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
