CODEWITHSUNDEEP
javajakarta-eeejbthread-local
Snake Eye
Snake Eye

Reputation: 535

ThreadLocal usage in enterprise application

If my web application and ejb application are on the same machine (on same JVM) and all the ejb calls are local calls , will the use of ThreadLocal create any issue while passing information from web to ejb?

Any workaround if the ejb calls are remote? Will ThreadLocal information be available from web application to ejb application? Is use of ThreadLocal advisable in such scenario?

Upvotes: 14

Views: 10059

Answers (7)

pgras
pgras

Reputation: 12770

For the first question, there is no problem as long as you remove the ThreadLocal variables at the end of every call. This is important because containers (servlet or ejb) typically use threadpools and therefore reuse threads, this has two effects: one "call" may see threadlocal info coming from a previous call, and if you remove an app from the container without stopping the JVM some classes may not be garbage collected because they are still referenced by a container thread. So put data in a threadlocal in a try / finally block and remove in the finally part.

Here is a post showing one way to handle the problem: ThreadLocal in web applications

For the second question as data is threadlocal it will not come with a remote call, you have to add a parameter to your interfaces, extract threadlocal data on one side and recreate it on the other side...

Upvotes: 14

lyuboe
lyuboe

Reputation: 171

ThreadLocal cannot be used with 100% certainty in web applications. You simply do not have the guarantee that one thread will be used for one session. In my point of view this can get a very hard to find security hole!

ctx.getContextData() does not work for me, it always returns null!

I also tried TransactionSynchronizationRegistry, but I get null as well.

The only thing that worked is using JAAS as a workaround.But it is not a nice solution.

Upvotes: 0

Soccertrash
Soccertrash

Reputation: 1901

ThreadLocal shouldn't be used in EJB contexts. One cannot guarantee that the EJB method invocations are all on the same thread (of course the should be).

In EJB there is a different approach call TransactionSyncrhonizationRegistry. See Explanation/Usage for further details.

Upvotes: 3

SpaceTrucker
SpaceTrucker

Reputation: 13546

When using EJB 3.1 you can pass around contextual information in the EJBContext using its context data. This is just a Map<String,Object>.

Upvotes: 3

Anton
Anton

Reputation: 6041

all the ejb calls are local calls , will the use of ThreadLocal create any issue while

No, you answered your question yourself. Since calls are local they are executed in the context of one thread.

Any workaround if the ejb calls are remote?

In case of remote calls, the Java EE container will be run in an other JVM, it will spawn its own threads to handle incoming RMI request, there is no way for a remote Java EE container to know about thread local variables that were declared on the other side. Pass it as a parameter object.

Upvotes: 2

nwinkler
nwinkler

Reputation: 54427

For local calls, the ThreadLocal should work fine, as long as everything is done in the same thread.

For remote calls, which can potentially run on a different server, you will need to come up with something else. Either pass all values as parameters (which will work, but introduces complexity in the code) or use something like a distributed cache, e.g. Hazelcast, which will function like a global HashMap, which all cluster nodes have access to.

Upvotes: 0

JeanValjean
JeanValjean

Reputation: 17713

It depends what information you are passing! The first question it too generic. I suggest to read the JavaDoc related to ThreadLocal here.

ThreadLocal lives from the server side of the application and are used to let Thread-safe the calls of your Thread objects.

Upvotes: 0

Related Questions