Stateless objects are objects with no properties. However when we talk about a stateless server, we are talking about an architecture where the objects do not retain state between requests. This does not mean that the data is lost between requests, it merely means that the data is somehow temporarily persisted during the business transaction, the process handling the request is terminated and the server resources are freed. A new request can, then, resurrect the temporarily persisted data and continue the business transaction.
HTTP servers are stateless, as is the HTTP protocol. Despite this, when we look at a shopping cart in a web shop, we have a session and the items in the cart are preserved between requests without the business transaction been finished and its data being permanently persisted. This makes it in fact a stateful session.
Storing session state
Client side
We can store the session on the client, as encoded data in the URL, using cookies, serializing data in a hidden form field or in an object in a rich client.
The downsides are that this data always needs to be transferred back and forward between client and sever even if it is not needed. This makes this option only suitable if the amount of data is not much. Another downside is security, if data is in the client side, can we trust it?!
Server side
Server side session data must be resilient to both client and server failures, it must be able to be handled by different servers receiving requests from the same client, and it must invalidate the data at a predetermined moment.
When to use what
Personally, I prefer to use server side session state when:
- The business transaction is not very long;
- The client software used for the transaction is the same from beginning to end;
For example, a shopping cart implementation where the user is supposed to use the same browser throughout the whole business transaction.
And use client side session state when:
- The business transaction may be very long;
- The client software used for the transaction might not be the same from beginning to end;
For example, a registration process, where the user uses a browser to start the registration process, then uses an email client to click a link that should return him to the same business transaction, and finally maybe even a different browser to finish the transaction.
@hgraca 