Top use cases for using Sessions in Java web application

I've been 开发者_JAVA技巧always trying to avoid using Sessions. I've used spring security or other ways of having user logged in the application, which is I suppose the major use case for using Sessions.

But what are the other use cases ? Could you please make a list of those most important ones ? How come that I've been able to develop even complicated applications without using Sessions?

Is it because I'm using spring-mvc and using Sessions is practically not needed except the login stuff ?

EDIT: Guys this question was asking for use cases... Most of the answers explains what are sessions for. If we summarize some usecases, we can say for sure, when to use database or sessions for maintaining conversation state... Don't you remember any concrete scenarios you needed sessions for? For past years :)

for instance some conversational state may become persistent after some point / event. In this case I'm using database from the beginning.

I think you can do anything you want without storing anything on a sessions.

I usually use the sessions to avoid having to pass state between the client and server (used id as an example) and when I don't want to send sensitive information to the client (even in encrypted form) as it might be a security problem.

Other ways of avoiding using the session are:

• store some state on a database, e.g. shopping carts, instead of in the session, even if the cart is discarded after a certain amount of time.
• store state in cookies e.g. for user customization

One use case when it's really useful to use the session is for conversations, although usually frameworks manage that behind scenes, and store the conversation in the session.

edit

Converstions (in my understanding) are something like wizards, in which you complete several forms in different pages and at the end you perform the action. e.g. in a checkout process, the user enters his name, shipping address and credit card details in different pages, but you want to submit the order just at the end, without storing any intermediate state in your DB.

By sensitive information I mean, imagine in the previous example, once the user sent his credit card details, you shouldn't return that information in any format (even encrypted) to the user. I know it's a bit paranoid, but that's security :).

In the ecommerce system i'm working on, there is an external system at the back-end which stores users' saved shipping and billing addresses. Our web app talks to it by making web service calls to retrieve those addresses. When we get the addresses, we store them in the session. That way, we only have to call the service once, when the user firsts looks at their addresses, and not every time we serve a page which needs address information. We have a time-to-live on the addresses, so if the addresses change (eg if the user telephones the customer service desk to change an address), we will eventually pick up the fresh ones.

It would be possible to store the addresses in our database, rather than in the session. But why would we? It's transient information which is already stored permanently somewhere else. The session is the ideal place for it.

Well in one sense your question is deep (what's SPECIAL about a session is worth knowing) and in another sense it's shallow (what can't I do if I don't use them turns out to be a somewhat odd question)

In the end a Session is merely (or could be) a ConcurrentHashMap (in fact it usually isn't that threadsafe) with a a key of unique session id passing as the cookie. You know why it's useful, but to answer you for use cases

• clustering (this is how state gets distributed across nodes)
• caching general state of the user and their objects (as opposed to reloading from db each time)
• built in methods for sessionlisteners to watch when someone is timed out, or attributes change. = used for by a lot of localization utilities

Can you do all this with a database or your own hashmap implementation/filter? Of course, there's nothing magical about Sessions. They are merely a convenient standard for having some objects follow a logged in user and be tied to the lifetime of that user's use of the application.

Why do you use Servlets? You could also implement your own socket level standard? The answer to that is using standard apis/implementations provides convenience and other libraries build upon them.

The cons are

• you are reinventing the wheel and some code that has been time tested
• you won't be able to use a lot of built in facilities for monitoring/managing/clustering/localizing etc.

Sessions are one way of maintaining conversational state across multiple requests (e.g. multiple stateless HTTP requests.)

There are other ways of implementing conversational state, for example, storing an authentication token or some suitable conversation id as a cookie and maintaining a store of conversation id to session state. (In essence, duplicating what the app server is doing when it provides sessions.)

That you haven't needed to use sessions means that your application either doesn't need conversational state or you've implemented it in a different way. For example, perhaps your application uses an authentication token (say a cookie) and persists all state changes to the database. With that kind of arrangement, there is no need for a conversation state.

Hi you can take an example of shopping cart because since Http is stateless protocol it does not maintain the status of the user who sends the request.

For e.g. If one user sends a request to buy camera from say eBay and after some minutes another user sends a request to buy laptop.

But since http is stateless protocol so server is not able to separate the request send by the users and may it happen that the bill of the laptop may be given to first user.

So through session we can maintain a particular entity over the server side for a particular user.