On Thu, Jun 03, 2004 at 07:41:30PM +0900, ian.wark wrote: : We have a really difficult problem that surfaces only once every week or so : in which request parameters : for requests from a particular mapping get mixed randomly with request : parameters from the same mapping : that occurred minutes before. : : Has anyone come across this before or know why it might be happening? How : we might avoid it?
"duplicate info for different people" usually means "instance variable where there should be a method-local variable" ----------There is a request instance variable in the bean, however the action creates a bean for each request inside the control method, so ----------I can't see there being multiple threads accessing the same instance variable. How are these request params being set? -QM ----------The short answer is: the application uses the struts framework and on this jsp, submitting is done via JavaScript form submits. Here are some more details. We can tell that is is the same session from the log. So it is the same user. The user does a search and comes up with a list of items. Each item in the list has a link that submits to a details screen that has the details of that particular item. On that screen various information is displayed and there are three buttons below. One called 'check', one called 'back' (ie back to the search list) and another one that is something like 'finished with'. After clicking the 'check' the 'finished with' button becomes pressable. All submitting is done via JavaScript form submits. The problem seems to occur after a sequence similar to the following: 1. User clicks the link to get to the detail screen 2. User clicks the 'check' button which submits the request to itself and updates the check status. 3. The user clicks another button. Which button is not clear because the parameter reads something equivalent to 'check eck' (Japanese equivalent) which does not exist. The button name is taken via JavaScript. The other strange parameter is alarmNo which picks up randomish information after the = sign. Normally there is just one number. Here is an excerpt of one mishappen request from our log. [POST]/AlarmDetail.do?finishUserId=&changeConfirmFlg=0&addDatet=2004/05/29 09:13:58A13:58&confirmExecUpdFlg=0&errfilepath =&alarmNo=39372=38932dFlg=039583 &alarmDetail=etc etc.. We thought at first that the reason might be because the button doesn't have a multiple press lock via Javascript, so that you don't accicentally submit twice. It does have a 'Do you really want to do this' style dialog box. But even if the user managed to submit twice, you don't get two requests getting bunged together. Another very outside chance might be memory leaks. We have closed all the statements in our SQL explicitely, but not the ResultSets. Does that make things little a bit clearer? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
