When are cookies are preferable than sessions?

public class ServletDemo extends HttpServlet{

    public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws IOException{

        response.setContentType("text/html");
        PrintWriter pw = respon开发者_JS百科se.getWriter();

        Cookie cookie = new Cookie("url","mkyong dot com");
        cookie.setMaxAge(60*60); //1 hour
        response.addCookie(cookie);

        pw.println("Cookies created");
    }
}

I am seeing Java Cookies concept . There is a lot of stuff on cookies , use it when small data needs to be stored on client side.

But could you please tell me , when should we use Cookies exactly ??

And when cookies are preferable than sessions ??

This one part of a whole set of design decisions relating to where we need to keep state information when several computers are involved in a system.

When you say "session" I suspect that you mean the HttpSession that servlet containers will manage for you. It's actually quite likely that the HttpSession is actually maintained by using a cookie: the cookie just holds some kind of a key to a table of sessions.

This pattern of passing some kind of reduced amount of data back to the browser and having the server keep track of the main stuff is also pretty common. Sometimes folks use all three: cookie for, say, the small stuff, HttpSession as a convenient cache, and the database for stuff they really care about.

There's lots of factors to consider, here's a few:

• How much data is it reasonable to send in a cookie, too much things are going to go slow.
• How secure is this? Servers often assemble lots more data then the user entered in this session, how confident are we that something sensitive can't be hijacked or read if we send it back to the browser in a cookie?
• How reliable is our choice of session mechanism? Lose the browser, lose that 5k holiday booking we were just about to buy? Lose the HttpSession on the server? Perhaps the same outcome? (Some app servers have session replication, but it's an overhead).

Personally, I find that usually the HttpSession API is so convenient that I never choose to use cookies. My rule of thumb is "if it's readily re-creatable keep it in the HttpSession, otherwise make sure it's persisted in a database, if necessary creating a database specifically for state management (and not forgetting the housekeeping of that database).

Examples of re-creatable things: Items retrieved from a database (we can always get them again), things that the user would not mind re-entering (say a few search criteria). Example of non-re-creatable: the 17 page completed insurance application form.

Cookies are less secure than sessions.

A session is fully-controlled by the server. In both cases the client needs to securely present authentic session data, but with cookies there are more opportunities to sneak a look at what's going on internally. The consequences of cookie theft are in general worse then the theft of an opaque session ID.

Cookies can be faster to develop with because the server doesn't have set up session databases and the like, but they're a lower-quality solution if you care about design.

To answer your specific question, cookies are preferable to sessions when cookies can do what you can't do with sessions. I see two reasons to use them:

• when you need some information about the client, and this information must keep existing across multiple client sessions, even if the user closes his browser. For example, an automatic login uses cookies: at the first request of a client session, the cookie is sent, and the web site is thus able to identify the user.
• when you need to share some information between information between several web applications, provided their are all served from the same domain. For example, single sign-on can use cookies. The first application authenticates the user and sets a token cookie, which is sent to the second application. the second application may then use this cookie to automatically authenticate the user.