This post talks about the differences between business and system transactions underlie much of the debate over stateless versus stateful sessions
Stateless means there is no record of previous interactions and each interaction request has to be handled based entirely on information that comes with it. To be more understandable, that means an object not doesn’t retain state between request.
Stateful means server keeps track a list of objects and this list must persist between requests.
The statefull server are cost of resources. If we want to track a user’s requests with a
stateful server object, we must have one server object per user. But 90 percent of the time they are just sitting around doing nothing. The point is that, if we have no state between method calls, it doesn’t matter which object services the request, but if we do store state we need to always get the same object. Statelessness allows us to pool our objects so that we need fewer objects to handle more users. So, statelessness also fits in well with the Web since HTTP is a stateless protocol.
The problem is that many client interactions are inherently stateful. The good news is that we can use a stateless server to implement a stateful session;
Session state is within a business transaction, which means that it’s separated from other sessions and their business transactions. Session state is distinct from record data, which is the long-term persistent data held in the database and visible to all sessions. Session state needs to be committed to become record data.
Not all data held by the session counts as session state. The session may cache some data that doesn’t really need to be stored between requests but is stored to improve performance. Since you can lose the cache without losing correct behavior, this is different from session state.
Store Session State
Client Session State (CSS) stores the data on the client. There are several ways to do this: encoding data in a URL for a Web presentation, using cookies, serializing the data into some hidden field on a Web form, and holding the data in objects on a rich client. Small data, encrypt data. Using CSS State for data that is pretty small, because CSS implies that with every requests, you have to transfer all data the server uses for it. And you need to worry about security and integrity.
Server Session State there’s a mechanism for storing the session state somewhere more durable as a serialized object. The object can be stored on the application server’s local file system, or it can be placed in a shared data source. This could be a simple database table with a session ID as a key and a serialized object as a value. Usually the Server Session State is the easiest on development resources, particularly if you don’t have to persist the session state between requests. A Good implementations of Server Session State should allow you to do clean session state after the period of time(automatic timeout operation).
Database Session State is also server-side storage, but it involves breaking up the data into tables and fields and storing it in the database much as you would store more lasting data. Since session data is isolated, you have to work hard to isolate the session data between users.
You can use a mix of two or three of them to store different parts of the session state. This usually makes things more complicated, however, as you’re never sure which part of the state goes in what part of the system. When doing this, you should keep at least a session identifier in Client Session State even if the rest of the state is held using the other patterns.