aspose file tools*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes I know local objects are thread safe. But why not obj here too? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "I know local objects are thread safe. But why not obj here too? " Watch "I know local objects are thread safe. But why not obj here too? " New topic
Author

I know local objects are thread safe. But why not obj here too?

Firas Zuriekat
Ranch Hand

Joined: May 09, 2006
Posts: 144
Consider the following servlet code:

public class MyServlet extends HttpServlet
{
final static int i=0;
public void doGet(HttpServletRequest req, HttpServletResponse res)
{
private HttpSession session=req.getSession();
private ServletContext ctx=getServletContext();
synchronized(ctx)
{
Object obj=ctx.getAttribute(); // code to alter obj
}
}
}

Which of the following variables in the above code are thread safe?

Choices:

* A. i
* B. session
* C. ctx
* D. req
* E. obj
* F. res

The answer is A , C , D , and F

Reason why D and F are correct:
Request and response objects are scoped only for the lifetime of the request, so they are also thread safe.

But why isn't E correct too? Isn't obj scoped for the lifetime of the block it's in? I mean after you leave the block, obj is NOT reachable so it should be thread safe, right?
Narendra Dhande
Ranch Hand

Joined: Dec 04, 2004
Posts: 950
Hi,



is not correct syntax for getAttribute.

Though you sync. on ctx. It can not be thread safe as the other code which are not sync the context can update the ctx. Same case for the obj.

So the ctx and obj can not be thread safe.

Thanks


Narendra Dhande
SCJP 1.4,SCWCD 1.4, SCBCD 5.0, SCDJWS 5.0, SCEA 5.0
Senthil Kumar
Ranch Hand

Joined: Mar 13, 2006
Posts: 264
Hi,
How come i will be threadsafe here?.Only request,response and local varibales are thread safe.Anything else are subject to cuncurrent thread
accesses


when you really want something, all the universe always conspires in your favour.<br /> <br />SCJP1.5-77%<br />SCWCD-89%
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489


How come i will be threadsafe here


Because 'i' has been declared final

ram.
Firas Zuriekat
Ranch Hand

Joined: May 09, 2006
Posts: 144
Though you sync. on ctx. It can not be thread safe as the other code which are not sync the context can update the ctx. Same case for the obj


But "obj" is defined in a block. So when you leave the block (I mean right after you reach the right brace), the object, "obj", becomes unreachable, right? I mean when another thread enters the block, it will create another "obj" becaue of the following declaration:
Object ob= ...

So it's thread safe. So why are you saying "obj" is not thread safe?

In other words, each time a new threads enters the block a new object, "obj" is created that is totally independed of the other objects created, right?

So how come it is not thread safe?

I am talking about "obj" and not the Object that "obj" points to.

Thanks very much
[ June 30, 2006: Message edited by: Firas Zureikat ]
Roy Simon
Ranch Hand

Joined: Aug 26, 2005
Posts: 62
hi
i, req and res are thread safe...

i is thread safe because it is declared final.
req and res are thread safe because there is only one object of each for each request... unless the goGet() or doPost() create threads and pass the request and response when creating them.

session objects are not thread safe.. it should be noticed here that a session object is not a local scoped object... the session is captured in the request via cookies.. so the state remains even after the service method completes...
the same can also be said about the servlet context and the Object 'obj' Eventhough the Object 'obj' has method scope.. it refers to a object(attribute) that can be accessed globally...

Regards
simon
Roy Simon
Ranch Hand

Joined: Aug 26, 2005
Posts: 62
I am talking about "obj" and not the Object that "obj" points to.

if the Object that obj points to is not thread safe... How can obj be thread safe.. ?? obj is just an handle that refers to the Object on the heap..

Regards
Simon
Firas Zuriekat
Ranch Hand

Joined: May 09, 2006
Posts: 144
sorry still don't get it. Look at the following:



I have 2 Questions:

Q1) Doesn't Line 2 above make the handle, obj, thread safe?
Q2) When the question asks about variables, does it really mean the objects the variables point to or the variables them selves? I mean is it asking about obj or the object that obj points to?

Again the questions is quoted as follows: "Which of the following variables in the above code are thread safe?". So regarding ctx, is the question asking about the variable itself (ctx) or the object that ctx refers to?
[ July 01, 2006: Message edited by: Firas Zureikat ]
Dilshan Edirisuriya
Ranch Hand

Joined: Apr 22, 2006
Posts: 299
In your first coding variable "i" is thread safe because it is final otherwise it's not.
yes Roy session objects are not thread safe. I agree
req and res are also thread safe because each thread holds unique req and res objects.

when the question asks about variables, yes it is really mean the object we are dealing with. Reference is only a bridge to call the object. It has a some sort of pointer to the desired object.
So by making ctx synchronized you try to synchronize the ServletContext. So modifications are not allowed from the other sevlets until the synchronized block finishes.

"Object obj=ctx.getAttribute();"
syntax is invalid. you must specify the String parameter as the argument.

By synchronized block you only synchronize the object which you pass as the argument. It doesn't synchronize objects which is inside the block. So in the first one it is not thread safe but your modified one it is thread safe as it is a final variable. But it still have the syntax error in getAttribute();


Dilshan Edirisuriya SCJP1.4, SCWCD1.4, SCBCD 5
Rex Saxena
Greenhorn

Joined: Nov 06, 2005
Posts: 3
Just to know this for my information... Why you are declaring method local variables as private? do they have any accesibility falgs associated with them . They are just the method local variables.
Ram Gokul
Ranch Hand

Joined: Oct 07, 2005
Posts: 85
Dilshan ,
As a beginer , I am trying to find out more.
In the explanation

"By synchronized block you only synchronize the object which you pass as the argument. It doesn't synchronize objects which is inside the block. So in the first one it is not thread safe but your modified one it is thread safe as it is a final variable. But it still have the syntax error in getAttribute(); "


When context object is synchronized , are'nt all context attributes synchronized as well . when context ( here ctx ) is synched out ,can someone access/change any of its attribute .In other words , if an Javaobject is locked , can someone change any of its properties using object setter methods ?

Thanks in advance
Dilshan Edirisuriya
Ranch Hand

Joined: Apr 22, 2006
Posts: 299
First of all you have some synatax errors in your second coding.
(I didn't see in the previous day)
How could you use final with static. It is contradictory.
I it is final it is thread safe.

And you can't use private variable inside a method. Method local variables are alwaya accessable within method scope only. You can make it final but don't use access modifiers.

So Rexs question,
When we setAttribute to ServletContext it holds a reference to a perticular object. Refer HFSJ example. So isn't there any possibility of changing the object without accessing through ServletContext ?
Dilshan Edirisuriya
Ranch Hand

Joined: Apr 22, 2006
Posts: 299
I think word "contradictory" above is misleading. Let me correct it.
You can't use final variable with static in this perticular situation.

In fact it's nothing to do with static, but remember when you declare final variables you have to initialize it as well(the purpose of making final static variable is to make that variable a compile time constant).

So in your second coding you have tried to assign many values to your final variable. It is totally wrong.

So I think you have got the idea about synchronization.
Read synchronization part of HFSJ. It clearly mentions that by making ServeletContext syncronized doesn't always make it's attributes thread-safe.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: I know local objects are thread safe. But why not obj here too?