I know the title looks like this post should go into the Servlets forum, but the servlet isn't my question.
When I was writing my servlet and asking questions about it I was advised to take out all variables. So I did. The only thing I have in my servlet are Object instances. Every time someone hits the doPost it will create an instance of the 3 objects I need so that I can populate my beans. This is all nice and clear to me now, but my question comes with the classes that I've written to do the processing.
What I'm trying to accomplish is that I need to populate a list of beans. I had this working but it wasn't in true MVC form so I have attempted to restructure it and now I'm getting an error. This is because my resultSet is returning null and when I do a .next() I get an sql exception error.
In my doPost I call a method called buildList(String) in my class ListOfBeans. buildList() returns a value of type List. My list i return will be an ArrayList of beans. I had not originally made my method static, but the compiler was yelling at me saying that "The method buildList(String) from the type ListOfBeans is not static". So I made it static and it compiles just fine.
Now, inside of buildList(String) I have to get a resultSet and add each row of the resultSet to my Bean and make that a row in my List. So I call an outside method called myRS(String) which is part of my class RS. I had to make myRS(String) static as well since it was yelling at me again.
So the question part... I know that instances are references to an object. But each object is created by calling static methods of classes. Is this way of doing things thread safe? If I have two hits at the same time on my server will I be stepping on myself with the static classes or will it be ok since I'm using instances in my servlet?
I'm not I understand you completely, however you may find the folloeing information useful:
When you have a servlet class, there is actually only a single servlet object instance in memory (you don't control that, this is performed by the servlet container).
So, if declare a class member in this servlet class, then each user activating a web request is using the same actual object, which is almost always not recommended.
If you want to make sure no user is 'stepping over' another users objects make sure you create local method variables and do the whole 'user specific request' with these objects. Otherwise, your objects are not thread safe.
As an exercise, you can try printing the objects's hashcode in each request. If it is the same hashcode, then it's not thread safe.
Joined: Nov 19, 2007
I was a little bit confused on some terminology. I went back and reread the post I was referring to in my mind. I understand that I have my servlet container. I only get one. My doPost will be called each time I have a request. Each request will open in its own thread. In each request I create instances of the objects that I need. These are 2 beans and a list of beans. The jsp will use EL to get values from my one bean, and iterate my list of beans. I know that my beans and list will be safe as they are a part of my request thread. But to get those instances I have to call some static classes. I was wondering if those static classes will step on each other if multiple requests are made to them or will they also be thread safe?
I hope this clears up my question...
I'm going to look into printing the hash table. I have never worked with it before. I'll post back if I have any problems.
Joined: Nov 19, 2007
Printed the hashcodes of my objects in my doPost. No matches. Nice and thread safe. I think my question is answered. And incase Bear is reading this...
static v instance methods have almost nothing to do with Threading proper. If you call new on something and do all the work in that instance without any calls to any static methods, then you may not need any synchronized methods. It's hard to tell what pre-written libraries do, but static may make protections worse, not better. synchronized keyword can be used to keep one thread from walking on another's data, if used correctly, but can also cross-lock the app into a dead-locked contention for things to lock on if any function tries to lock on two or more variables.