On Mar 10, 2009, at 6:10 AM, is_maximum wrote:
Hello
In our application we contract to have request informations in all
the DTOs
coming from the clients. So in order to make these information
accessible
across the application in request scope I have defined a class in
which a
ThreadLocal is defined as final static and also a default
interceptor that
extract the request information from the method parameter using the
InvocationContext.
But now it seems that this ThreadLocal doesn't work in container.
Since
inside a service method a bunch of services from other SLSBs will be
called,
my gues is that container may or may not create new threads for them
so we
can't rely on this ThreadLocal benefits.
My question is if I am right how we can make this information
accessible in
request scope across the application just like old programs that
uses the
magic of thread local.
I appreciate of you share your experience on this
ThreadLocals definitely work, we use them extensively. There's only a
few places in our code that will launch a new thread.
- EJB Times. We have a thread pool for executing the bean's @TimeOut
method.
- Any calls made on the RemoteInitialContextFactory. It uses one
thread to call the blocking serverSocket.accept(), when a connection
is made and the socket is handed over to a thread pool for execution.
All calls made on this are going to be from user code, meaning we
don't have any internal code that relies on it. Internally all non-
webservice calls are made over the IntraVM Server (i.e.
LocalInitialContextFactory) which doesn't create any threads. So
calls made from one EJB to another over a business interface are
guaranteed to be in the same thread.
- WebService calls. If bean A invokes bean B over bean B's
webservice interface. That is essentially making a remote call
locally and bean B will be executed in a different thread than bean A.
- MessageDriven bean calls. All of these are asynchronous and
guaranteed to be executing in a different thread than the code that
produced the message.
You mentioned in a previous email that you had code that created jobs
and executed them in a separate thread. I'd double check that if you
haven't already. Any ThreadLocal state you or we set in the bean's
thread A are not going to be seen by the job in new thread B.
Technically speaking the ejb spec says starting new threads is against
the rules as new threads by definition are completely outside the
management of the container's thread state where security,
transactions, jndi naming, and other state is kept.
Despite it being illegal, starting your own threads can be awfully
handy. If it is your new thread that is lacking the state you set in
the parent thread, you could possibly use a
java.lang.InheritableThreadLocal to get the state propagated.
-David
