In this lesson we're going to take a look at complementary scopes, scopes outside of session. We have request and ServletContext, sometimes called application scope. We're going to take a look at those. We've already been dabbling a bit, so it's about time to really understand them. What you'll be able to do after this lesson is demonstrate how to share data amongst server-side or container resources, fully understand request scope, its purpose and when to use it, define and use a ServletContext also known as the application scope, and explain when to use request or session or application so that we are being as efficient with memory as we can possibly be. Sharing data between resources. In the servlet API we have a lot of options for where data can be stored and retrieved by the resources in a web application. Typically we have to worry about servlet to servlet or servlet to JSP, and the areas where we store these things are called scopes because remember the servlet and JSP themselves are stateless. There's three methods for all scopes. We've already done sessions so everything that was true for session the good news is, there's great naming conventions and you're going to find that request and ServletContext are named very similar. A session we saw that we could say set attribute and pass in a string as the key and an object, because the value we could get attribute given the key and it would return the object then we would need to downcast it, and we could remove an attribute by its name in the map as well. What scopes are available? Well, there are basically three and each level stores data that will typically persist longer. Longer means more overhead for the server ultimately and more to keep track of. As a guideline, you want to store your data in the smallest or most narrow scope possible. Request is available for the life of a single HTTP request. It's best used for passing that one time use data to the container and maybe I'm going to go from a servlet to a JSP and I want that piece of data to last for that request and that's it. A session we've already looked at quite a bit, it's multiple requests, it's having a conversation with the server and container much like the behavior of a shopping cart. A ServletContext is used less rarely but it is very powerful it should have really been named application scope, because it's available for the life of the application. When you put something up there in that particular map it's shared amongst all of the servlets in the application or JSPs or other resources. It's best used for data shared among all instances of our servlet and container resources. Servlet request is our smallest scope and it's used to pass data from one resource to another, we've already dabbled with this. Just remember it's tied to a single request and it lives only as long as that request is being processed. Once that request is done and the response has been sent back, the request scope is destroyed and that data no longer exist. We prefer storing data here unless it's needed for a larger scope. The good news is with all servlets and JSPs their thread-safe, each request runs in its own thread, and the even better news is that the container manages that for us. Session scope you're already experts at by now. It's a larger scope, it's tied to a single client and it spans multiple request. It will live as long as that particular client session is active and it generally thread-safe unless a user opens two browser windows and starts doing things they really shouldn't be doing. Now the ServletContext is the largest scope the global or application level if you will and it's shared amongst all the servlets and JSPs for all clients for our web app, and it'll stick around as long as the web app is running. It is not thread safe because it's a very shared piece of memory. Let's look at some code to add items to a scope. This should be pretty familiar to you because again you did it with session and you're going to find it's very similar in each case. Here we say request getParameter username, and we're going to get that out of the request parameter coming in off our URL, and we're going to set that in our request scope by calling set attribute passing in a key and then using our name variable to pass the object up. Same thing here, we're going to say request getParameter we just use an address in this case, but we get the session for my request object and we set the attribute in our session. Surprised, we're going to do the same thing we've got a name maybe we want to share the Coursera name across all of the pages, and we're going to put that in our attribute but first we've got to get the context so we get our ServletContext and then we can say context.setAttribute and pass in the company. Just remember that that second argument gets up cast to an object. Watch what's happening over in my table view if you will. I like to think of these as tables in memory it just helps me visualize and so there's the HttpServletRequest, there's the HttpSession, and there's the ServletContext. You can see the name value pairs being put up there. What about getting items from a scope? Well, it's exactly the way we've been doing you call request, getAttribute you send in the name of the key and your objects is a return and will need to be cast down to whatever it was. It works the same way in all three, so no big surprises here at all. Again as I'm getting stuff out you can just see where it's coming from you can see the keys, you can see the values, and just remember you're downcast. Well, now I want to share data with scopes. What happens? What's going on? Servlet 1 is going to store ZipCode object in the request scope. Under the lookup name ZipCode now pay attention in this particular example to capitalization because it is the source of many bugs and we put it in here like this on purpose so you just get used to looking. Servlet 1 will store a ZipCode optic capital Z capital C in a request scope under the lookup name and it's camelCase, lowercase zipcode. It then request to Servlet 2, and Servlet 2 will retrieve the ZipCode object by looking at the request scope for ZipCode. It writes a response to the client, the connection is closed and the request scope is gone because the request is finished. Again I create a ZipCode object. I'm using a local variable name of zip, but then I set the attribute in the request scope with the key ZipCode camelCased and the variable zip. I have to make sure in Servlet 2 when I get my ZipCode back, I can say request getAttribute ZipCode. Notice that the name in the case of the attribute the key have to match, and then obviously it returns an object so I have to cast it down to a ZipCode
