Hi Heath,
Is creating our own threads in the web container a bad thing?
Maybe bad is a little bit too much, but I would rather stay away of that. The container does a lot of effort to synchronize the data access. This is not an easy task if you consider that many times an execution thread is associated with a transactional context, etc. So inside of the container things are very complex to manage. If you start your own execution thread, then you�re on your own. You must deal with data access, transactions, etc. Unless you don�t have a very strong reason for doing this, you better stay away.
Another thing that you might consider is that the container also manges the threads in a very optimal manner. WebLogic for example has a message-oriented architecture. It creates something named execution queues that could be configured to pool a specific number of threads. Applications can be associated with this execution queues for parallel processing. If your application starts another thread(s) arbitrarily, then WebLogic has no choice but to take more threads from the queue, while other client request will be blocked. If you kill the thread, then the queue will lose the thread and you�re application performances might degrade considerably. Again think twice in orde to open the Pandora�s box.
If not, is creating a database connection in the calling thread and setting it into the runnable object for use a valid way to do this?
Why not to use the connection pooling feature that your container provides?
Regards.