AW: How to handle requests in quick sessions / possible thread issue

2002-10-11 Thread Ralph Einfeldt 

There is no general answer to this.

There are following common options:

- Deny request until the first is finished:

  static Boolean cMutex = new Boolean(true);
  static boolean cRunning = false;



  // in the method that performs the processing
  synchronized (cMutex) {
 if (cRunning) {
   // return [error]message
 } else {
   cRunning = true;
 }
  }
  try {
// Do what ever has to be done
  } finally {
cRunning = false;
  }  

  (Just one approach, there are several others)

- Serialize Requests

  synchronized void doSomething() {
   // Do what ever has to be done
  }

- Stop the first request
  Depending on the code that you want to perform for
  the request this can get very tricky.

- run them multi threaded
  To do that your code must be thread safe,
  and your database code must be designed in a way
  that the threads will not lock each other. What
  you have to do to achieve this, depends on you own 
  code and the locking strategy of the database. 
  (Wether it has Table-, Page- or Row- locking)

 -Ursprüngliche Nachricht-
 Von: Michael Nicholson [mailto:[EMAIL PROTECTED]]
 Gesendet: Donnerstag, 10. Oktober 2002 17:53
 An: Tomcat Users List
 Betreff: OT: How to handle requests in quick sessions / 
 possible thread
 issue
 
 So, I now have an Oracle backend that's supposed to be 
 accessed by jsps and servlets.  Which works.  However, if a 
 user gets impatient (I know, it never happens, but just in 
 case!), then while the database is doing it's thing, the java 
 process receives a new request and starts a new thread, 
 right?  But this is a problem in that it stops responding.  
 Entirely.  I don't know if this means that my db connection 
 got closed midway through the second process (which should 
 now have the request and response instances that my browser 
 wants back), and therefore it's sitting there going which 
 way did it go, which way did it go (you have to imagine the 
 silly cartoon voice), or what.  And I don't really know that 
 connection pooling will help.
 

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

OT: How to handle requests in quick sessions / possible thread issue

2002-10-10 Thread Michael Nicholson 

So, this is my first project where I need to manage a large number of concurrent 
requests.  And, to make things worse, most of my previous experience in programming is 
Visual Basic for Applications running in either Excel or Access.  (Don't worry, it 
gets more on topic...)

So, I now have an Oracle backend that's supposed to be accessed by jsps and servlets.  
Which works.  However, if a user gets impatient (I know, it never happens, but just in 
case!), then while the database is doing it's thing, the java process receives a new 
request and starts a new thread, right?  But this is a problem in that it stops 
responding.  Entirely.  I don't know if this means that my db connection got closed 
midway through the second process (which should now have the request and response 
instances that my browser wants back), and therefore it's sitting there going which 
way did it go, which way did it go (you have to imagine the silly cartoon voice), or 
what.  And I don't really know that connection pooling will help.

Now, more experinced minds than mine have solved this before.  Most commercial/decent 
sites seem to handle it fine:  do they simply interrupt the old process and then start 
a new one?  Should the beginning of my db-routine have something like:

Connection con = null;  //to close any currently running process on this connection in 
this object/bean/servlet
try
{
  crap;
} catch (crappyException ce) {
  handle it
}  finally  {
  if (con!=null)
  {
con.close();
con=null;
  }
}

Would that solve my problem?  Or do I need to let the first request finish itself and 
then start a new one?  Any ideas?

Thanks for your time.

Michael Nicholson

Re: How to handle requests in quick sessions / possible thread issue

2002-10-10 Thread Michael Nicholson 

ok, yes, I'm dumb... the subject should have said How to handle requests in
quick succession / possible thread issues

Mike


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]