Two problems are actually being discussed here. First is a single user that
has multiple DataOutputStreams assigned to him/her and the second is a host
of DataOutputStreams communicating with a host of users in no discernable
order. It sounds like the best solution would be a combination of the
suggestions below. First, either use JavaScript to control Submit requests
or in your doGet or doPost methods, immediately flush out a "Content-Type:
text/html\r\n" response to the client so that their browser clears in
anticipation of the new page (I've done the later and it works). Second,
use the SingleThreadModel to control user synchronization. I have not
played with this, but if you have a decent machine it may be worth the extra
resource usage.
My 2 cents.
Dave
----- Original Message -----
From: Venkat Nimishakavi <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 07, 1999 11:14 AM
Subject: Re: more threads write to the same result page
> Well, we can ask User not to click Submit button more number of times.
(or
> use Java Script as suggested).
>
> But, in a real world scenario, what happens if a set of 50-75 users use
> same servlet (almost at same point of time - may not be exact )
>
> I faced similar scenario, when in single user mode, my Servlet works fine.
> But, if more users (say 25 - 30) invoke the servlet while using the
> application, the resultant HTML page is jumbled/messed up. I guess other
> users data is getting displayed on some other's page (we called it in our
> group as Bleeding of Data or Data Spill Over !!!) .
>
> Then I implemented servlet as SingleThreadModel and the problem was
solved.
> I was able to repeat the problem by NOT implementing as SingeThreadModel.
> So, I came to the conclusion that, same instance of Servlet is getting
> multiple requests and it is unable to decide to send What to Where (i mean
> which user).
>
> Using SingleThreadModel, an instance of Servlet will process only one
> request at a time and it is able to decide to send resultant page to which
> user.
>
> My application (it's an internal tool) is being pounded by 40-50 users and
> it behaves perfect.
>
> Using SingleThreadModel we get easy thread safety at the cost of increased
> resource requirements (b'cause more servlet instances are created) and it
> may result in degradation of performance. But I felt it's better than data
> bleeding.
>
> I tried the above mentioned scenarios on Java Web Server and WebLogic
> server. Both behaved in similar fashion.
>
>
> Thanks
> Venkat
>
> > -----Original Message-----
> > From: Kevin Mukhar [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, December 07, 1999 9:11 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: more threads write to the same result page
> >
> > No, SingleThreadModel won't solve this problem. The web server/servlet
> > engine
> > will still handle concurrent requests. The difference is that with
> > SingleThreadModel, each request will be sent to a different instance of
> > the
> > servlet, rather than as a separate thread to the same instance.
> >
> > How to solve this problem? Don't click the "submit" button more times at
a
> > very
> > fast speed. Seriously. Sure it's a problem if one of your user's does
> > this, but
> > it's a problem they've created themselves by doing something they
> > shouldn't have
> > done.
> >
> > One approach I've seen is to use JavaScript in the web page to set a
flag
> > when
> > the submit button is clicked the first time. This flag is checked
whenever
> > submit is clicked, and subsequent clicks are ignored if the flag was
> > previously
> > set. This solution fails when the user clicks the stop button before a
new
> > page
> > is received or if the response comes back in a new window.
> >
> > Kevin Mukhar
> >
> > Venkat Nimishakavi wrote:
> > >
> > > Try running your servlet in SingleThreadModel
> > >
> > > > -----Original Message-----
> > > > From: Zou hua [SMTP:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, December 08, 1999 3:19 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: more threads write to the same result page
> > > >
> > > > Hello all,
> > > >
> > > > I have a servlet that uses Cookies. When I click the "submit" button
> > from
> > > > the HTML page once, it works well. If I click this button more times
> > at a
> > > > very fast speed, then the returned page looks very strange. It seems
> > there
> > > > are more than one datastreams being writen in the same result page.
> > > >
> > > > I have checked my log file. it seems there is only one seesion
> > associated
> > > > with these clicks, of course, this is what I expected. But more
than
> > one
> > > > servlets ( or threads) runs for these click, maybe each click is
> > > > associated
> > > > with one . Some of them can catch IOException and some of them
catch
> > > > NULLPointerException when they try to write to
> > > > "response.getOutputStream()".
> > > >
> > > > How to solve this problem?
> >
> >
__________________________________________________________________________
> > _
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
