Servlet, threads and StaleConnectionException

Hi folks,
we're currently developing an J2EE application in which we have to works with threads started and stopped via web interface: on a test JSP page, we have a button to start the thread and another button to stop the same thread. At the moment, we have just one thread which periodically checks some data on a DB installed on the same machine on which the application server runs.
The problem is, when the thread is restarted, a StaleConnectionException is thrown, which code SQL1224N The DB is DB2 from IBM and the application server is WebSphere 5; both of they run on a Linux Red Hat system.
We use a JDBC Connection provided by the application server.
We can't understand where is the problem. We suppose that the problem is creating independent threads from a servlet, as J2EE paradigm suggests not to do so. Is there anybody that encountered the same (or similar) problem ? Any suggestion ?
Thanx a lot in advance.
Claudio.

Hi Claudio,
hope this helps ...
http://archive.midrange.com/java400-l/200301/msg00039.html
WS App Throwing a StaleConnectionException
Q: My WebSphere application is throwing a
com.ibm.websphere.ce.cm.StaleConnectionException. What is the problem?
This exception indicates that the connection is no longer valid. Here are some
possible causes of it:
1)The database management system is down.
2)The application previously closed the connection.
3)The connection has been orphaned, which means that the application has held
the connection for too long without using it. The Data Source property "Orphan
timeout" specifies the maximum number of seconds that an application can hold a
connection without using it. If an app holds a connection without using it
beyond the Orphan timeout value, WebSphere may return the connection to the
connection pool. If the connection is returned to the connection pool, and the
application then tries to use the connection, the Stale ConnectionException is
thrown.

Similar Messages

Servlets, Threads and ThreadNames and Tomcat!

Hi gurus's
I found something interesting but am not sure if this is in the servlet container spec.....
When a new client request comes in, servlet serves that request on a separate thread. Now I change the thread name for some requests. I found that servlet container (Tomcat 4.1.24 in my case) seems to be reusing the threads to serve client requests. i.e when another request comes in (after the first request has finished) the thread name is still set to what I had set it to during the first request....
This implies that Tomcat actualyl re-uses the threads it creates to serve client requests. I thought that it would create a completely new thread for each request.
Does anyone know anything about this??? Or is this in the spec for container writers where they start n number of threads and just pool these threads and re-use them to serve client requests???
I would appreciate your help because this causes problems with my logging mechanism as I rely on unique thread name...

The servlet specs does not require servlet containers to start a new thread for each request.
For performance purposes, most, if not all, servlet containers re-use threads to service requests.
You may want to switch over to the Log4J (http://jakarta.apache.org/log4j) logging mechanism. Its concept of Nested Diagnostic Contexts (NDCs) is much better than relying on the uniqueness of thread names.

Servlets, Threads, sleep and wait

Hi,
I am new to servlet programming and have a problem.
I want to create a servlet that is also Runnable. It should hold the HTTP request open, and then wait() or sleep(), waking up regularly to send data to the client.
My code seems to work OK, and in the server logs I can see the debug messages where my servlet is sleeping and waking up. However, it doesn't keep the connection open. Instead, any clients that try to connect instantly receive an empty response.
Can anyone explain why this is? I am a bit lost. Is the server (Tomcat) cutting my request off when I start to sleep or what?
dave

OK. Now seems like I have it working with sleep().
I was doing something pretty dumb and assuming that a new HttpServlet instance was created for every request - doing things like this.request = request; - obviously this didn't work too wlell ;-)
Now just using Thread.sleep() it works much better
One more question - how can I get a separate servlet to call notify() on this servlet so that it wakes up and delivers its message? (I know I need to call wait() not sleep())
Thanks
dave

Problem regarding servlets+ threads

<meta http-equiv=\"refresh\"" " content=\"5\" ";URL=\"\">";
Iam using meta refresh tag for refreshing browser for every 5 seconds.
When i invoke doPost () then iam creating thread and for every 5 sec it calls doGet() .
If i close browser then servlet is not invkoing but thread is running
How to stop a thread when we close browser?

iam using Tomcat
<Connector acceptCount="100"
connectionTimeout="20000"
disableUploadTimeout="true" port="8080"
redirectPort="8443" maxSpareThreads="75"
maxThreads="150" minSpareThreads="25">
</Connector>
his is ok.Ignore my first post.
Your problem has nothing to do with the containers thread management.
Is there any way to excute following method
Thread.currentThread().destroy(); or stop when i
close browserPlease see malcolmmc's great post (i.e, the browser refresh is driving things - you shouldn't need a thread in the servlet).
Servlets are blocking request / response based: When you've written a response, you're done. They are not connection based - and there isn't (and shouldn't be) any direct way to know when a connection has gone

Security & Servlet engine and ejb container on different servers

          When you have the servlet container and the ejb container on different physical servers,
          how is the rmi connection meant to to be done while still maintaining the seucrity
          propagation from servlet to ejb tier?
          Assume that my user is already authenticated (forms) on the servlet tier. Do we then
          create a dedicated connection (InitialContext + url/username/password properties)
          to the ejb tier and store this connection in the HttpSession? (basically authenticating
          a 2nd time)
          OR,
          can the servlet container make a generic connection to the ejb container, and pass
          the users security context to the ejb tier transparantly?
          -Sam


Nick Minutello <[email protected]> wrote:
          > Assuming that web container security is being employed, I guess the fundamental question
          > is: Is it necessary to create a "connection" (ie. an InitialConext) per user, or
          > can a "global" initial context be shared (in the end, the TCP connection is shared
          > anyway)?
          It doesn't create a 'connection' per user - when you use JNDI authentication (specifying
          principal and credentials when constructing InitialContext) it associates security info
          with the current thread for the duration of the request. If you cache InitialContext and
          use it later on some other thread it will not do anything.
          > Does it really matter?
          No ;-)
          > Thanks,
          > Nick
          > "Dimitri I. Rakitine" <[email protected]> wrote:
          >>Nick Minutello <[email protected]> wrote:
          >>
          >>
          >>> OK, so when I create the InitialContext, I just specify the URL (to call
          >>the remote
          >>> EJB container). The user ID and credentials are mapped automatically.
          >>
          >>> I obviously also need to cache the initialContext variable in my HTTPSession
          >>object?
          >>
          >>> What would happen if I had one InitialContext for the whole servlet engine
          >>- and
          >>> each thread used that. Would the thread (security) context still get passed
          >>- or
          >>> would the credentials for the original connection get used?
          >>
          >>If you use web-app security, container will associate security info with
          >>the current
          >>thread before invoking your servlet. If you do not use it and cache InitialContext,
          >>
          >>then the current user will always be 'guest' (except for the very first
          >>time when
          >>application calls 'new InitialContext()' with username/password.
          >>
          >>
          >>> Thankyou.
          >>> -Sam
          >>
          >>
          >>> "Vinod Mehra" <[email protected]> wrote:
          >>>>
          >>>>"Sam the bad cat" <[email protected]> wrote in message
          >>>>news:[email protected]...
          >>>>>
          >>>>>
          >>>>> When you have the servlet container and the ejb container on different
          >>>>physical servers,
          >>>>> how is the rmi connection meant to to be done while still maintaining
          >>>>the
          >>>>seucrity
          >>>>> propagation from servlet to ejb tier?
          >>>>>
          >>>>> Assume that my user is already authenticated (forms) on the servlet
          >>tier.
          >>>>Do we then
          >>>>> create a dedicated connection (InitialContext + url/username/password
          >>>>properties)
          >>>>> to the ejb tier and store this connection in the HttpSession? (basically
          >>>>authenticating
          >>>>> a 2nd time)
          >>>>>
          >>>>> OR,
          >>>>> can the servlet container make a generic connection to the ejb container,
          >>>>and pass
          >>>>> the users security context to the ejb tier transparantly?
          >>>>
          >>>>If the user has logged in already, ie the authenticated user is already
          >>>>in
          >>>>the execute
          >>>>thread, the identity should be propgated to the ejb tier transparantly,
          >>>>when
          >>>>you create the
          >>>>new initial context.
          >>>>
          >>>>--Vinod.
          >>>>
          >>>>
          >>>>>
          >>>>> -Sam
          >>>>>
          >>>>>
          >>>>
          >>>>
          >>
          >>--
          >>Dimitri
          >>
          Dimitri

Multiple Servlet Threads - per HttpSession

          Can there be concurrent Servlet threads on a single HttpSession in cases where
          there are multiple frames on the Browser Window, or if the user has multiple Windows
          open in the same Browser session? Or is it the case that the multiple requests
          on that HttpSession are synchronized to be done in sequence (WebLogic 6.1 as Web
          Server).
          If there can be concurrent threads then how are non-repeatable reads handled for
          objects stored in the HttpSession. For example two threads pick up object A from
          HttpSession, and overwrite each other changes when they set them back in HttpSession.
          Thanks,
          Pradeep


          Thanks but how does that protect against non-repeatable reads?
          Even if there is a synchronized session object in HttpSession still nothing to
          stop from concurrent threads from overwriting each other's settings if the threads
          picked up a value from session object, did some processing and wrote it back.
          (This is almost an optimistic concurrency type scenario)?
          Pradeep
          Alexander Petrushko <[email protected]> wrote:
          >Pradeep Behl wrote:
          >
          >> Can there be concurrent Servlet threads on a single HttpSession in
          >cases where
          >> there are multiple frames on the Browser Window, or if the user has
          >multiple Windows
          >> open in the same Browser session? Or is it the case that the multiple
          >requests
          >> on that HttpSession are synchronized to be done in sequence (WebLogic
          >6.1 as Web
          >> Server).
          >>
          >> If there can be concurrent threads then how are non-repeatable reads
          >handled for
          >> objects stored in the HttpSession. For example two threads pick up
          >object A from
          >> HttpSession, and overwrite each other changes when they set them back
          >in HttpSession.
          >
          >It's up to the application to prevent the threads from stepping on each
          >other when it
          >comes to HttpSession. You can create a thread-safe session class, store
          >your session
          >objects in the instance of that and then have HttpSession store the thread-safe
          >impl.
          >
          >Cheers,
          >
          >Alex
          >
          >

Servlet Threads

i have a servlet written. i wanted to make it multi-threaded so that if the request is taking time to be processed then another request will not have to wait.
so when the request comes in, i start a new thread and pass the HttpServletResponse to that thread. Then the servlet is free to accept other requests.
the problem i am having is that when the browser makes the request, i can see on the server through debug that the correct information is being built but nothing is being written back on the outputstream?
am i threading the servlet wrong? or should i be using a different means?
thanks,
hande.

Servlets are already multi-threaded and should be able to handle multiple requests.

Servlet thread pool

Is there any way I can create my own init() for the threads in the servlet thread pool (by overriding some method or through other means)? (Not to be confused with the servlet's init().)

web server itself is a thread pool implementation, unlesss your thread has other purpose, if not it is suited and enough for you do not implement another thread for it. If you want some init method, you can call from other class before start of your thread pooling.
Hopefully can help you...

Servlet Thread Pools for iPlanet WS 4.1

We have iPlanet WS 4.1 SP 5, running on HP UX. Wanted to make sure servlets run fast, so set up servlet thread pool. Initial result was that even the startup servlet could not be loaded, got stack overflow. Reduced number of threads from 60 to 5. Now startup servlet kicked off OK, but a subsequent servlet processing a request bombed with same error. This is obviously some kind of resource issue; how does one allocate enough memory or whatever it needs to handle the thread pool? Do I really even need a thread pool?

Thanks, and a follow-up question: at that reference, it seemed to imply there is really no need to allocate a user thread pool if running on Unix. Could even slow down the application. Am I likely to be OK with about 300 concurrent users if I don't allocate a thread pool? I was afraid they'd be single-threaded through the front controller servlet if I did not specifically allocate and use a thread pool, but perhaps multiple threads are already built into the container?

Are servlets thread safe??

Are servlets thread safe?? if not, then how to make them thread safe.

Hi,
servlets aren't thread-safe; you can make them thread-safe by implementing the interface javax.servlet.SingleThreadModel
From the javadoc:
public interface SingleThreadModel
Ensures that servlets handle only one request at a time. This interface has no methods.
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
If a servlet implements this interface, the servlet will be thread safe. However, this interface does not prevent synchronization problems that result from servlets accessing shared resources such as static class variables or classes outside the scope of the servlet.

A problem with Threads and MMapi

I am tring to execute a class based on Game canvas.
The problem begin when I try to Play both a MIDI tone and to run an infinit Thread loop.
The MIDI tone "Stammers".
How to over come the problem?
Thanks in advance
Kobi
See Code example below:
import java.io.IOException;
import java.io.InputStream;
import javax.microedition.lcdui.Graphics;
import javax.microedition.lcdui.Image;
import javax.microedition.lcdui.game.GameCanvas;
import javax.microedition.media.Manager;
import javax.microedition.media.MediaException;
import javax.microedition.media.Player;
public class MainScreenCanvas extends GameCanvas implements Runnable {
     private MainMIDlet parent;
     private boolean mTrucking = false;
     Image imgBackgound = null;
     int imgBackgoundX = 0, imgBackgoundY = 0;
     Player player;
     public MainScreenCanvas(MainMIDlet parent)
          super(true);
          this.parent = parent;
          try
               imgBackgound = Image.createImage("/images/area03_bkg0.png");
               imgBackgoundX = this.getWidth() - imgBackgound.getWidth();
               imgBackgoundY = this.getHeight() - imgBackgound.getHeight();
          catch(Exception e)
               System.out.println(e.getMessage());
      * starts thread
     public void start()
          mTrucking = true;
          Thread t = new Thread(this);
          t.start();
      * stops thread
     public void stop()
          mTrucking = false;
     public void play()
          try
               InputStream is = getClass().getResourceAsStream("/sounds/scale.mid");
               player = Manager.createPlayer(is, "audio/midi");
               player.setLoopCount(-1);
               player.prefetch();
               player.start();
          catch(Exception e)
               System.out.println(e.getMessage());
     public void run()
          Graphics g = getGraphics();
          play();
          while (true)
               tick();
               input();
               render(g);
      * responsible for object movements
     private void tick()
      * response to key input
     private void input()
          int keyStates = getKeyStates();
          if ((keyStates & LEFT_PRESSED) != 0)
               imgBackgoundX++;
               if (imgBackgoundX > 0)
                    imgBackgoundX = 0;
          if ((keyStates & RIGHT_PRESSED) != 0)
               imgBackgoundX--;
               if (imgBackgoundX < this.getWidth() - imgBackgound.getWidth())
                    imgBackgoundX = this.getWidth() - imgBackgound.getWidth();
      * Responsible for the drawing
      * @param g
     private void render(Graphics g)
          g.drawImage(imgBackgound, imgBackgoundX, imgBackgoundY, Graphics.TOP | Graphics.LEFT);
          this.flushGraphics();
}

You can also try to provide a greater Priority to your player thread so that it gains the CPU time when ever it needs it and don't harm the playback.
However a loop in a Thread and that to an infinite loop is one kind of very bad programming, 'cuz the loop eats up most of your CPU time which in turn adds up more delays of the execution of other tasks (just as in your case it is the playback). By witting codes bit efficiently and planning out the architectural execution flow of the app before start writing the code helps solve these kind of issues.
You can go through [this simple tutorial|http://oreilly.com/catalog/expjava/excerpt/index.html] about Basics of Java and Threads to know more about threads.
Regds,
SD
N.B. And yes there are more articles and tutorials available but much of them targets the Java SE / EE, but if you want to read them here is [another great one straight from SUN|http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html] .
Edited by: find_suvro@SDN on 7 Nov, 2008 12:00 PM

Problem with threads and ProgressMonitor

Dear Friends:
I have a little problem with a thread and a ProgressMonitor. I have a long time process that runs in a thread (the thread is in an separate class). The thread has a ProgressMonitor that works fine and shows the tasks progress.
But I need deactivate the main class(the main class is the user interface) until the thread ends.
I use something like this:
LongTask myTask=new LongTask();
myTask.start();
myTask.join();
Now, the main class waits for the task to end, but the progress monitor don`t works fine: it shows only the dialog but not the progress bar.
What's wrong?

Is the dialog a modal dialog? This can block other UI updates.
In general, you should make sure that it isn't modal, and that your workThread has a fairly low priority so that the UI can do its updating

Having a problem with threads and using locks

I was hoping someone could give me some hits on getting my code to run properly. The problem I am having is I think my locks and unlocks are not working properly. Plus, for some reason I always get the same output, which is:
Withdrawal Threads         Deposit Threads            Balance
Thread 2 attempts $29 Withdrawal - Blocked - Insufficient Funds
Thread 4 attempts $45 Withdrawal - Blocked - Insufficient Funds
Thread 6 attempts $34 Withdrawal - Blocked - Insufficient Funds
Thread 7 attempts $40 Withdrawal - Blocked - Insufficient Funds
                                Thread 1 deposits $187          $187
                                Thread 3 deposits $169          $356
                                Thread 5 deposits $61           $417
Press any key to continue...If someone can see the error I made and doesn't mind explaining it to me, so I can learn from it, I would appreciate that very much.
/************Assign2_Main.java************/
import java.util.concurrent.*;
public class Assign2_Main
{//start Assign2_Main
    public static void main(String[] args)
    {//start main
           // create ExecutorService to manage threads
           ExecutorService threadExecutor = Executors.newCachedThreadPool();
        Account account = new SynchronizedThreads();
        Deposit deposit1 = new Deposit(account, "Thread 1");
        Deposit deposit2 = new Deposit(account, "Thread 3");
        Deposit deposit3 = new Deposit(account, "Thread 5");
        Withdrawal withdrawal1 = new Withdrawal(account, "Thread 2");
        Withdrawal withdrawal2 = new Withdrawal(account, "Thread 4");
        Withdrawal withdrawal3 = new Withdrawal(account, "Thread 6");
        Withdrawal withdrawal4 = new Withdrawal(account, "Thread 7");
        System.out.println("Withdrawal Threads\t\tDeposit Threads\t\t\tBalance");
        System.out.println("------------------\t\t---------------\t\t\t-------\n");
        try
            threadExecutor.execute(withdrawal1);
            threadExecutor.execute(deposit1);
            threadExecutor.execute(withdrawal2);
            threadExecutor.execute(deposit2);
            threadExecutor.execute(withdrawal3);
            threadExecutor.execute(deposit3);
            threadExecutor.execute(withdrawal4);
        catch ( Exception e )
             e.printStackTrace();
            //shutdown worker threads
           threadExecutor.shutdown();
    }//end main
}//end Assign2_Main/******************Withdrawal.java****************************/
public class Withdrawal implements Runnable
{//start class Withdrawal
      *constructor
    public Withdrawal(Account money, String n)
         account = money;
         name = n;
    public void run()
    {//start ruin
         int newNum = 0;
            newNum = account.getBalance(name);
           Thread.yield();
    }//end run
    private Account account;
    private String name;
}//end class Withdrawal/*******************Deposit.java***************/
import java.util.Random;
public class Deposit implements Runnable
{//start class Deposit
      *constructor
    public Deposit(Account money, String n)
         account = money;
         name = n;
    public void run()
    {//start run
            try
                 Thread.sleep(100);
               account.setBalance(random.nextInt(200), name);
            }// end try
            catch (InterruptedException e)
              e.printStackTrace();
   }//end run
   private Account account;
   private Random random = new Random();
   private String name;
}//end class Deposit/********************Account.java*****************/
*Account interface specifies methods called by Producer and Consumer.
public interface Account
     //place sum into Account
     public void setBalance(int sum, String name);
     //return value of Account
        public int getBalance(String name);
} /**************SynchronizedThreads.java****************/
import java.util.concurrent.locks.*;
import java.util.Random;
public class SynchronizedThreads implements Account
{//start SynchronizedThreads
      *place money into buffer
    public void setBalance(int amount, String name)
    {//start setBalance
         // lock object
         myLock.lock();
        sum += amount;
        System.out.println("\t\t\t\t" + name + " deposits $" + amount +"\t\t$"+ sum+"\n");
           //threads are singnaled to wakeup
        MakeWD.signalAll();
          // unlock object
        myLock.unlock();
     }//end setBalance
      *gets the balance from buffer
     public int getBalance(String name)
    {//start getBalance
         int NewSum = random.nextInt(50);
         //lock object
        myLock.lock();
        try
             if(sum > NewSum)
                 //takes NewSum away from the account
                 sum -= NewSum;
                    System.out.println(name + " withdraws $" + NewSum +"\t\t\t\t\t\t$"+ sum+"\n");
            else
                 System.out.println(name + " attempts $" + NewSum + " Withdrawal - Blocked - Insufficient Funds\n");
                 //not enough funds so thread waits
                    MakeWD.await();
            //threads are singnaled to wakeup
            MakeD.signalAll();
            }//end try
        catch (InterruptedException e)
               e.printStackTrace();
        finally
             //unlock object
             myLock.unlock();
        return NewSum;
     }//end getBalance
     private Random random = new Random();
     private Lock myLock = new ReentrantLock();
     private Condition MakeD = myLock.newCondition();
     private Condition MakeWD = myLock.newCondition();
     private int sum = 0;
}//end SynchronizedThreads

You can also try to provide a greater Priority to your player thread so that it gains the CPU time when ever it needs it and don't harm the playback.
However a loop in a Thread and that to an infinite loop is one kind of very bad programming, 'cuz the loop eats up most of your CPU time which in turn adds up more delays of the execution of other tasks (just as in your case it is the playback). By witting codes bit efficiently and planning out the architectural execution flow of the app before start writing the code helps solve these kind of issues.
You can go through [this simple tutorial|http://oreilly.com/catalog/expjava/excerpt/index.html] about Basics of Java and Threads to know more about threads.
Regds,
SD
N.B. And yes there are more articles and tutorials available but much of them targets the Java SE / EE, but if you want to read them here is [another great one straight from SUN|http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html] .
Edited by: find_suvro@SDN on 7 Nov, 2008 12:00 PM

Java threads and WinLogon processes taking CPU!

We are seeing a strange problem. We have a multi-threaded java application
that is deployed on a Microsoft Windows 2000 server (SP4) with Citrix
Metaframe XP (Feature release 2). When this application starts, we start to see
multiple WINLOGON.EXE processes (20 plus) each taking up 1-2% of CPU -
this raises the CPU usage on the server significantly, impacting performance.
We have tested with JDK 1.3, 1.4, and 1.5 and see the same issues. If we
run the java application in a single thread, we dont see the same issue.
Has any one seen this problem before? Any suggestion on how this can be resolved?
Thanks in advance!

Thanks for your replies. This is a Citrix environment where there are 50 plus
users logged in and there are 50 plus instances of Winlogon.exe always
running. Most of the time the cpu usage of these processes is 0.
We tried a multi-threaded program that lists files in a directory every few
seconds. There are 40 plus servers in the farm that we are deploying this
application on. We are seeing this problem on only some of the servers.
If we run a single thread from main(), we dont see the issue. But if we spawn
10 threads doing the scans periodically, we notice that as soon as all the threads
start, the WinLogons appear to start to take up CPU. When we stop the java
program, the WinLogon processes drop in CPU usage.
Is it possible that Java and WinLogon share some dlls that could be triggering
the WinLogon processes off?
We have tried running the single thread and multi-threaded programs around
same time and the correlation with the winlogons is clearly visible. If we add
sleep() soon after we start a thread, the winlogons seem to kick in later.

Handling Threads and Memory

I'm sorry if this is a cross post to my StringBuffer problem. I have run a test that instantiates the object in question and the memory gets collected so I don't think it's that. My question is on how memory pertaining to Threads is handled.
In my application I have a Thread array that launches X number of Threads. Currently 5. When an object wants a job run, the static Thread pool looks at the current thread and sees if it is still working. If it is, we sleep until it is available. Then I give it another job to do, start it, and move to the next thread.
Question 1 -
In a Thread [] is it better to replace the Thread at position x as in
threads[a] = new Thread();
threads[a].start();
or is it better to change some parameter in the thread and then call
start() again?
Question 2 -
I am currently using the second method. In my Thread object I have a MessageObject which contains a StringBuffer, which is eating memory. These MessageObject's are increasing. Some are being collected but many are staying live in the system and causing a memory error. When I do the following....
MyThread.MessageObject = new MessageObject()
That should make the original object available for cleanup right?
Should I call finalize on the MessageObject before replacing it?
Thanks you for any insights.

If you want to use thread pools, and you can use JDK 5.0 (formerly known as J2SDK 1.5, codename Tiger), try using the java.util.concurrent package instead of writing your own thread pool (it's really difficult to make a thread pool right).
If you can't use JDK 5.0, you can try the original util.concurrent package ( http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html ) from Doug Lea. It's used in the JBoss Application Server, so it's tested and reliable.
If you need to use an object pool, try using the Commons Pool Component from Jakarta Apache: http://jakarta.apache.org/commons/pool/

Servlet, threads and StaleConnectionException

Similar Messages

Maybe you are looking for