Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception to the rule: don't declare member variables in servlets?

 
Oliver Chua
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've heard of the maxim don't declare member variables in servlets or in classes that servlets call, but I think this is thread safe because the MyAbstract class has no member variables, just local variables, and local variables are stored in their own heap, meaning there is a separate copy per thread.

Is this considered thread safe?

public abstract class MyAbstract{
public void myAbstractMethod(StringBuffer message);
public void myMethod(){
StringBuffer localVar="";
myAbstractMethod(localVar);
}
}


public class MyImpl extends MyAbstract{
public void myAbstractMethod(StringBuffer message){
//...
}
}

public class MyFacade{
private static MyImpl m=new MyImpl();

public static void facadeMethod(){
m.myMethod();
}
}
 
Oliver Chua
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By the way, I originally posted this in Threads section, but
according to Ernest Friedman-Hill:
>>Indeed, this has nothing to do with threads that I can see. Moving to the Servlets forum.
The post did not appear here so I am reposting.

Let me just say that I feel my post has at least something to do with threads and that I feel that it was unfair to imply that I am incapable of following directions. I wonder if moderators take their time to really understand the question before moving posts to other forums...

>>CL Gildert: Well since you have not declared any member variables, what's your question?
I declared a member variable inside the MyFacade class.
The MyFacade class will be called from the Servlet.

>>I am concerned about the static variable though. If the whole JVM is reinstantiated you will get a new static variable, so I wouldn't expect that variable to be shared between instances since instances can be in different JVM, AFAIK.
I think that will only be an issue if the servlet will be deployed as distributable. Since we will not be doing that, i don't think it will be a problem.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13074
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've heard of the maxim don't declare member variables in servlets or in classes that servlets call

Not a very good statement of the maxim. Try this
Never use member variables in servlets for data that changes with each user since many requests may be executing "at the same time".
When talking about classes used in servlets, you have to make the distinction between:
1. There is only one instance used by all requests/sessions (for example a connection pool)
2. Each request/session gets its own instance.
It should be obvious by now that the maxim applies to 1 but not to 2.
Bill
 
Oliver Chua
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there Mr. Bill Brogden,

So nice to hear from you!
I've read two of your books: Java 2 Exam Cram and Java Servlets and JSP.

You're explanation implies that the code is really thread safe.
Thanks for the help.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13074
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Oliver!
There is in fact one special case in which an object instance unique to a user session in not automatically Thread-safe. That can occur because you can actually have multiple requests from the same user, with the same session, processing at the same time.
For example - if your HTML page is composed of frames or if you are generating images or other resources. All of those requests will share the same session.
Something to keep in mind...
 
Gary Seibold
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. Does this mean you should not use init() to initialize variables used other places, like database connections. Is there some way to pass non-member variables to init?
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13074
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. Does this mean you should not use init() to initialize variables used other places, like database connections. Is there some way to pass non-member variables to init?

The operation of init has nothing to do with the problem of what kind of member variables are Thread-safe. The servlet engine only calls init() one time - after the servlet class has been constructed but before any request has been processed. The init method is where your servlet class learns about the environment it will be operating in - the ServletContext - and has a chance to use initialization paramters from your web.xml plus other resources you may have defined for the servlet context.
Since init is only called once, while the servlet instance may remain in memory for weeks, you should not use init to create anything with a limited lifespan, such as a database connection.
Bill
 
Daniel Hedrick
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oliver,

I think that the strictest answer to your question "is [my design] considered thread safe?" is probably, technically, yes. However, that's not to say this is a good, practical OO implementation. I'm no expert, but trying to decypher what's going on in your MyFacade.facadeMethod() is confusing.

I suggest you don't let Servlet implementation details (ie their singleton nature) inhibit your ability to write well-designed objects.

Consider this:

java.lang.Thread.currentThread() returns the current thread.
java.util.Map.put(Object o, Object o) allows you to store any object in a map implementation using any other object as its key in the map.

Now, it is possible using these tools to build a thread-local caching mechanism that will allow you some limited ability to store variables in your servlet in a thread-safe manner. One major gotcha is remembering to pull the myCurrentThread out of the map just before you're leaving your execution scope (ie the Servlet.service(...) method). Consider patterns such as Factory or Observable for implementation details.

Good luck!

-daniel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic