From what I understand this all stems from the fact that you are
dealing with transactional programming. I would suggest the following
measures:
1) Reduce the size of the dataset, if you don't need to keep all of the
data in one table, don't. If possible cache data in another table in the
DB and use referential constraints to maintain integety (A pain, but it can
yield good results.)
2) The advice on indexing is valid. A large table, when normalized and
indexed is much faster.
3) Check your DB connect options, (if using JDBC) you may be able to set
caching options or rowset return options. The sooner you get something
back from the DB, the sooner you can find out the connection is broken and
cancel the request.
4) Send the client something like "Please stand by...", it'll keep them
from canceling and resubmitting the request. (Server push pages work
great for this.)
Good DB programming practices will take you farther in this case than
tweaking your Java classes.
On Wed, 27 Oct 1999, [utf-8] PATIBANDA, SRIKANTH wrote:
> >
> >
> > "PATIBANDA, SRIKANTH" wrote:
> > >
> > > Scenario 1:(the request is trying to retrieve 5 rows out of
> > some 500,000
> > > rows in the database.)
> > >
> > > lets say a user sends dopost request to servlet.. a thread
> > is created..
> > > and user is waiting for a response.... Meanwhile user
> > clicked the stop
> > > button
> > > on the browser...(I mention here its the browser button) it
> > means from
> > > the user side the request has been cancelled..
> > >
> > > But if you check the JavaWebServer, the thread is still hanging out
> > > there...
> > >
> > > (you can know whether this thread is still going on or not at
> > > admin applet-->manage-->monitor-->resourceusage-->start view
> > > you can see under handler threads total---> avaialble...)
> > >
> > > my question comes here.. when does this thread die... or it
> > will be there
> > > till it completes
> > > the request...
> >
> > As far as you, the servlet writer is concerned, the thread
> > runs until it comes
> > to the end of the method called by the servlet engine,
> > usually doPost. Of
> > course, since the thread is created in the servlet engine, it
> > actually continues
> > to run after the servlet completes, until it comes to the end
> > of the method
> > start() in the servlet engine.
>
>
>
>
>
>
> >
> > When the caller presses the stop button (or makes another
> > HTTP request before
> > receiving the servlet's response), the thread runs until the
> > servlet tries to
> > write to the output stream, at which point an IOException is
> > thrown. If your
> > servlet catches the IOException, then your servlet could
> > gracefully complete. If
> > your servlet does not catch it, or catches it and rethrows
> > it, the servlet
> > server probably catches it and should terminate the thread gracefully.
>
>
>
>
>
> >
> > > or
> > > is there any other way to kill this thread...
> >
> > As has been discussed many times in this newsgroup, there is
> > no good way to know
> > the user has interrupted the output stream, other than to
> > catch the IOException
> > when your servlet writes to the output stream. Thus there is
> > no easy way to end
> > the thread until the servlet is ready to respond back to the caller.
>
> I am very disappointed by the bug, that there is no other solution to stop
> the thread at any point.
> Because, my problem is i have to access few rows of data from a million rows
> in a table.
> and when user stops the request abruptly, my thread is running till it
> complets... since it will take long time to
> access those few rows from a large table... its eating up all my
> memory....and making my another request very slow in responding....
>
> >
> > > Reason for this to be killed or stopped is: it slowing the
> > javawebserver
> > > drastically. I can not make another request
> > > till this thread dies or stops.
> >
> > Given a well behaved servlet server, and a correctly written
> > servlet, you should
> > be able to make as many requests as you want. Remember where
> > this started:
> > servlets are multithreaded. By definition, this means that
> > you CAN make more
> > requests at any time because the servlet engine will start a
> > new thread to
> > service the request.
>
> What actually i mean is i can make another request immediately but its not
> getting processed
> as quickly as it does when no other thread runs.....
>
> i am not using any synchronized modifier...
>
> then why my second request takes so much time to get the data......
> does it realted anything to the memory available...
> does this relates to something "managing the webserver"
> or
> does it require any particular way of coding..
>
> i want to write some effiecient servlets... where 10-15 users can access
> simultaneously...
> then at a time 20 threads will be activated(max)... then it slows down very
> much to get the data..
> but if they do one by one its very fast..what could be the problem....
>
>
> >
> > What I think you meant is that subsequent requests are not
> > serviced until the
> > first request completes. My first guess is that you
> > synchronized a section of
> > code and created a bottle neck. There are other ways to make
> > a servlet class
> > thread safe without synchronizing.
> >
> > Kevin Mukhar
> >
> > ______________________________________________________________
> > _____________
> > 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
