Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Repeated Variable names in same JVM

 
Sathish Nagappan
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers,
Let's say I have a Application Server (J2EE container) on which I have uploaded a servlet.

The source code of the servlet's doPost() method is:

{
1:BeerModel bm=new BeerModel(request.getAttribute("construct"));
2:String advice=bm.getAdvice(request.getAttribute("combo"));
}

Ok , now if this servlet is being accessed by many clients , means that that many threads will be created. Now every client will be running the same code. Hence the object reference bm will be created that many times. Would'nt it be a problem when client 1 executes line 1 and client 2 executes line 1 soon after. Then the object which was created due to client 1's execution of line 1 will get replaced by client 2's object rite ?? How do we handle this ?? maintain a seperate set of objects of the same name for each client ?
 
dennis du
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, I think JVM will garentee the safety for you.

You should not care about this kind of things.
 
Edisandro Bessa
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ashwanth,


Would'nt it be a problem when client 1 executes line 1 and client 2 executes line 1 soon after. Then the object which was created due to client 1's execution of line 1 will get replaced by client 2's object rite ??


Definitely not !

According to snipped code you provided above, the bm variable is local to doPost method.

It's just like a simple call to other method in a simple plain old java object. As soon as the doPost method fisnishes, the bm variable vanishes and the reference becomes eligible for garbage collection.

However, keep in mind that request attributes, session attributes and context attributes are all shared by any thread created to serve a given request, regardless of the servlet you are accessing such attributes. So, if you want to ensure that only one thread is the owner of some object reference in a given moment, you have to make sure that every part of your application that accesses such attribute is using sinchronization.

Hope that helps.
 
Rick Roberts
Ranch Hand
Posts: 59
Hibernate Java Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The request object is thread safe so you dont have to worry about it.

However HttpSession objects and ServletContext objects are not thread safe.

Hence:


and:

 
Sathish Nagappan
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great answer by Ms. Bessa... the others were also helpful. Thanks , that was what I was looking for !!
[ October 17, 2006: Message edited by: ashwanth fernando ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic