About Question enthuware.jwpv6.2.726 :

Moderator: admin

Post Reply
gurpreet_asrgndu
Posts: 55
Joined: Thu Jan 03, 2013 7:51 am
Contact:

About Question enthuware.jwpv6.2.726 :

Post by gurpreet_asrgndu »

the question asks to choose which is correct.

the correct answer according to the simulator is

to use session, the client browser must support cookies.

the explanation goes like this:

you can support sessions using URL rewriting as well. the explanation contradicts/proves the answer is wrong(not always true).

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.jwpv6.2.726 :

Post by admin »

The correct answer is option b. Option d, which you've quoted is not a correct option.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

Viorel Ghelbert
Posts: 15
Joined: Fri Apr 10, 2015 12:53 pm
Contact:

Re: About Question enthuware.jwpv6.2.726 :

Post by Viorel Ghelbert »

Hi,

I have a question about the last option:
By default, a session is thread safe.
Explanation:
It is not.
I've seen several questions which claim that the session is not thread safe, but technically it's not true:
Servlet Specification 3.0 wrote:7.7 Important Session Semantics

7.7.1 Threading Issues

Multiple servlets executing request threads may have active access to the same session object at the same time. The container must ensure that manipulation of internal data structures representing the session attributes is performed in a thread safe manner. The Developer has the responsibility for thread safe access to the attribute objects themselves. This will protect the attribute collection inside the HttpSession object from concurrent access, eliminating the opportunity for an application to cause that collection to become corrupted.
So the session itself is thread-safe, but the attributes may or may not be, depending on how they've been coded by the developer.

The same is probably true about the ServletContext, although I cannot find anything about its thread-safety in the specification.

My question is: does the real exam use the same terminology, where thread-safe actually means "will normally not be accessed by multiple threads concurrently"?

Thanks,
Viorel

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.jwpv6.2.726 :

Post by admin »

You are right. This option is too ambiguous to answer. The specification mandates that the internal data structures of session must remain consistent even if the session is accessed from multiple threads. The attributes themselves may or may not be thread safe depending on the class of those attributes.

However, safety of internal data structures of the session object is not the only issue here. Consider this situation, for example : You are storing the number of requests made by a client in the session using an Integer object. At the start of each request, you do the following -
session.setAttribute("totalrequests", new Integer( ((Integer) session.getAttribute("totalrequests"))+1) );

In this situation, you can see that even though session object as well as the attribute are thread safe, yet, it is not a safe way to keep a count of number of requests.

This is the aspect that the exam trying to get at in some questions. Some candidates have reported getting questions that might be a bit ambiguous from this perspective. You will have to see the question and answer it based on your interpretation of the problem statement.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.jwpv6.2.726 :

Post by himaiMinh »

Hi,

Code: Select all

session.setAttribute("totalrequests", new Integer( ((Integer) session.getAttribute("totalrequests"))+1) )
The container maintains thread safety for the internal structure of the session. That means session object is thread safe. Only one request can access session object at a time.
But why the above code example is not thread safe ?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.jwpv6.2.726 :

Post by admin »

Because there are two different calls to session (setAttribute and getAttribute ) in that statement and they are not within a single synchronized block.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.jwpv6.2.726 :

Post by himaiMinh »

So, if I have this code :

Code: Select all

 synchronized (session){

   session.setAttribute ("totalRequest" , new Integer (session.getAttribute("totalRequest"))+1);
 }

then, the session will be synchronized.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.jwpv6.2.726 :

Post by admin »

Well, it is not the session that will be synchronized. It is the code that you are executing in the synchronized block that is synchronized with any other code block that synchronizes on the same session object. This is basic OCPJP stuff.

-Paul.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 22 guests