The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enter-
prise bean must not attempt to manage thread groups.
1. Use a profiler in RAD to see if the objects created by the unmanaged threads are garbage collected ? Run your server in profile mode for x amount of minutes , force a gc then view the profiling output. There should be a column in the profile view of objects collected.
BM don't recommend you create unmanaged threads due to some of the reasons listed in the following linkhttp://www.ibm.com/developerworks/websphere/techjo...cott/0609_alcott.html#spring-4 such as preventing graceful shutdown, releasing resources, unable to create an InitialContext (i believe new InitialContext() in unmanaged threads returns null) etc.
Unmanaged threads are unknown to WebSphere Application Server and do not have access to Java EE contextual information.
In addition, they can use resources without WebSphere Application Server knowing about it,
I think they have an alternative approach to doing custom threading using the WorkManager API see http://www.ibm.com/developerworks/websphere/techjo...0606_johnson/0606_johnson.html
In terms of your application design why do you need to create these lists in a thread in an infinite loop ? Are you using this servlet as a sort of batch job scheduler ?
Instead of running the first select statement you could have each channel(jsp, web services) send a message to an mq queue instead of adding a row to a database. The mdb listeners for a message on that queue and processes it as it receives them. Its possible to configure multiple instances of mdbs which acts like your 12 threads.. You also don't need to worry about the row locking (select for update) as the container services handle the synchronizing access to each message. .