Indeed, it can seem *spooky* to start writing code at the ThreadLocal level ... but remember, threads are created, assigned, collected and reused by the server - unless explicitly created by the application (which is highly discouraged), they are managed by the server.
That said, the server receives a request, grabs a thread and assigns it to the request. I believe you can assume that same thread will start, service and end requests consistently. The OS may context switch and control may move (the thread may pause) but unless someone is trying to make their own lives extremely difficult, threads in a JEE container will not jump around randomly from request to request without completing them. (I think this might be specified in a JSR somewhere - but I can't put my finger on it right now.) -Luther On Wed, Jun 10, 2009 at 10:39 AM, James Carman <[email protected] > wrote: > On Wed, Jun 10, 2009 at 11:34 AM, Frank Tegtmeyer<[email protected]> wrote: > > I think you hit the problem here. The example I used (in German at > > http://rattlab.net/2008/10/persistenz-fur-den-feedreader/) implies > > that every Request uses its own thread and I never expected threads to > > be reused. I used simple initialization of the variable and closed the > > EntityManager in onEndRequest(). > > That highlights why I didn't like the ThreadLocal() approach - it > > depends on implementation details somewhere out of my control (and > > knowledge). > > The specification says that threads may be reused. So, it's not > really an implementation-specific thing. Most servers implement their > server threads this way, as they should. You should expect them to > reuse threads. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
