File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

InheritableThreadLocal behaviour

 
subba nadendla
Greenhorn
Posts: 3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have an application using weblogic server.

In my application, during any EJB method call the user will login and will logout after the EJB method
call completes.

Once we logged in, I am keeping a the user pricipals in a thread local (inheritable) variable called as
Subject.

During any weblogic request, the user can invoke n number of beans and the Subject is held in the
thread local variables.

Now there are some background threads which are started through Startup servlents. These threads also
periodically invoke the beans and the created subjects are held in its thread local variable.

Since all the weblogic requests and background tasks are carried out through different threads,
one thread shouldn't see/get another threads subject.

But some how, the weblogic execute request threads are able to see the background startup servlet created
thread subjects.

As per Java InheritableThreadLocal concepts this shouldn't happen.

Suppose if the background threads are not running then the weblogic request threads works fine.

only when the background threads also parallel running then I can this descrepency.

When I make my Subjects variable as ThreadLocal instead of InheritableThreadLocal variable it works
100% fine.

I guess weblogic request threads and Start up Servlet created threads are independent. So this shouldn't
happen even if I use InheriableThreadLocal variable instead of ThreadLocal.

So the total summary is if i my subject variable as ThreadLocal it works 100% fine, if I mark it as
InheritableThreadLocal then it gives the problem.


Can you please suggest why this is happening like this ?

Is there a way weblogic execute threads will have a relationship with the StartUpServlet created threads ?

Please see a copy of the Subject.java which holds the user priciples and with a thread local subject..

=========================================================
import java.security.Principal;
import java.util.*;

public class Subject {
private static ThreadLocal _subjects = new InheritableThreadLocal();

private Set _principals;

public Subject(Set principals) {
_principals = principals;
}

public Set getPrincipals() {
return _principals;
}

public Set getPrincipals(Class type) {
Set principals = new HashSet();
Iterator i = _principals.iterator();
while (i.hasNext()) {
Principal principal = (Principal) i.next();
if (type.isAssignableFrom(principal.getClass())) principals.add(principal);
}
return principals;
}

public static Subject getSubject() {
try {
return (Subject)getStack().peek();
} catch (EmptyStackException e) {
return null;
}
}

public static void setSubject(Subject subject) {
if(subject==null){
if(!getStack().isEmpty()) getStack().pop();
}
else{
getStack().push(subject);
}
}

private static Stack getStack() {
if (_subjects.get() == null) {
_subjects.set(new Stack());
}
return (Stack)_subjects.get();
}

}
Thanks
Subba.
 
Steve Luke
Bartender
Pie
Posts: 4181
21
IntelliJ IDE Java Python
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since all the weblogic requests and background tasks are carried out through different threads,
one thread shouldn't see/get another threads subject.


That isn't exactly how I understand it when you use InheritableThreadLocal (ITL). When you use an ITL then your child threads have access to the parent thread's values. So if your background threads and the request threads share the same parent then they would be sharing the same parent thread values, which is apparently what you are seeing:

[ September 25, 2008: Message edited by: Steve Luke ]
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Putting aside the problem you have in hand.
I have one question. Why are you getting to maintaining these subjects rather than use weblogic security and the identity(subject) propagation infrastructure that weblogic provides?

In case you are unaware of it, here are a few relevant articles:
Introduction to WebLogic Security
Managing Security
 
subba nadendla
Greenhorn
Posts: 3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Steve,

thanks for the reply.

I understand what you are saying.

But in this scenario, the subject got created by the individiaul threds when they call the beans.

The thread local variable got assigned only when the execute threads / background threads invokes the EJB call.

before the EJB call if you check the subjects, it will be null.

As per my understanding the main thread is not accessing/initializing the subjects thread local variable.

Can you please confirm and suggest whats wrong with this ?

Thanks
subba.
 
subba nadendla
Greenhorn
Posts: 3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nitesh,

Thanks for your reply. This project was rolled out in year 2002. Thats why still continuing on the original design instead of redesigning the same..

thanks
subba.
 
Steve Luke
Bartender
Pie
Posts: 4181
21
IntelliJ IDE Java Python
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by subba nadendla:
As per my understanding the main thread is not accessing/initializing the subjects thread local variable.


You have to consider InheritableThreadLocal as Parent's Thread Local. When you get() or store() on an InheritableThreadLocal you are get() and store()ing the Parent thread's object. This can be modified by subclassing InheritableThreadPool and overriding the childValue method to make a ThreadLocal copy if you want children to see snap-shots of the parent value without ability to modify it.

Typically, though, you should not be using InheritableThreadLocal objects on anything that can change because it is not thread-safe.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic