Curious to know how thread pooling works in j2ee

[Mahesh Trikannad]

Iam curious to know how thread pooling works in j2ee and in general.

I have a Logger utitlity, that extracts the current logger context by using the thread id. This allows utility classes to log, without having to pass them any Logger objects.

When I was testing this on a MDB, I discovered that a pooled MDB instance, can be associated with different threads. I print the thread id in setSessionContext where it always shows main. Then I keep a thread variable and check for changes in the onMessage. It does change, proving the fact that a particular pooled MDB instance actually gets different threads allocated.

I know Thread pooling and MDB pooling are different. Quite curious to know how they all work together.

Mahesh

[Stan James]

That's an interesting thought-problem. I don't know about EJB so this is guesswork, but a neat way to manage work is with blocking queues. When you want something you try to get it from a queue. If there is one there, you get it immediately. If there are none there you block until somebody puts one back into the queue.

So when the container needs an instance of BeanX it goes to the BeanX queue. It might get one right away, it might wait. If requests for a particular bean come in faster than they can be handled, the queue will may be empty and block.

Then the container builds a command object that will execute BeanX and puts the command into a queue. When some thread becomes idle it goes to the queue for a command. If the requests are coming in faster than they can be handled, the queue will likely pile up a bunch of pending commands and the thread will get one right away. If the threads are keeping up with demand, there may be one or more threads blocked on an empty queue, waiting for a new command.

Does that sound reasonable? Anybody know if it's true?
[ January 12, 2005: Message edited by: Stan James ]

[Mahesh Trikannad]

Weblogic uses Execute Queues, to run EJBS , servlets, etc.

Can anyone confirm if Execute Queues work the way, Stan has explained.

Thanks Stan for the reply. I was thinking for some time my ramblings would be ignored.

Mahesh

[Stan James]

I'm pretty sure my first reply was backwards ... you'd want to get the thread from the thread pool first and have the thread get the bean from the bean pool.

[David Harkness]

Essentially, that's how it works. The container manages a pool of some number of threads (specified by configuration) that loop forever, handling requests from a queue. I don't recall if WebLogic has separate thread pools for servlets versus EJBs. For remote EJB calls it could be handy, but for calls to local EJBs it would force the servlet thread to sit idle while another thread handles the EJB call.

I'd bet BEA's docs goes into detail if you want more.