Objective 3.2 is the only objective to talk about multi-threading. The exact wording is "... and identify multi-threading issues associated with each scope." Each scope meaning of course request, session and application. Each scope allows one to use the set/getAttribute() method to store/retrieve objects. You will have to know in which circumstances access to objects in each of the scopes is thread-safe or not. The context scope is not thread-safe as objects stored in it are accessible to any servlet in the web application. For instance, think about a list stored in the context scope. One servlet stores/removes elements in/from the list and another servlet just lists the content of the list. What would happen if the first servlet removes an element from the list while the second is enumerating it? Right, IndexOutOfBoundsException. Two solutions: either you synchronize access to the list (=> bottleneck) or you create a temporary copy of the list before enumerating it in the second servlet (=> costly in case of big lists). The session scope may not be thread-safe either in the case the user opens multiple browser windows and performs several concurrent requests to the web application. Same example as before, the first servlet (accessed in one window) adds and removes elements from a list stored in the session scope. The second servlet (accessed in another window) just enumerates the elements of the list. If the user removes an element from the list in the first window and tries to enumerate the list in the second window at the same time, we also get the infamous IndexOutOfBoundsException. Again, two solutions: synchronize access to the list or synchronize the session object. The request scope is always thread-safe because a new request object is created (or reused) upon each new client request. Therefore, there is no way two threads may be accessing the request object simultaneously unless you create multiple threads in the service method that access the request object. Also, it might be good to know that local variables are always thread-safe because each thread executing a method will get a new copy of the local variable. Static variables are never thread-safe because they are shared by all instances of the class and instance variables might not always be thread-safe depending on the threading model (thread-safe only when implementing the SingleThreadModel interface which is now deprecated). Briefly, I think this is what one should know for the purpose of the beta exam. Happy learning [ January 07, 2004: Message edited by: Valentin Crettaz ]