Enthuware

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).

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

HTH,
Paul.

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

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.

Hi, 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 ?

Because there are two different calls to session (setAttribute and getAttribute ) in that statement and they are not within a single synchronized block.

So, if I have this code : then, the session will be synchronized.

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.