Maintaining state in the application server or in the database?

REST advocates web applications without client state on the server. The famous shopping cart example is translated to a resource which typically resides in a database.

I wonder if it is a good practise to use a开发者_如何学运维 database for that kind of data, since the database is already the bottleneck in many applications. Wouldn't it be better to use a stateful enterprise java bean instead? Application servers are designed with clustring in mind.

What are the advantages and disadvantages of the two approaches?

Storing sessions on the application server will only work if:

• Your clients always connect to the same application server (aka "session affinity")
• Your application cluster nodes all use a common mount point (nfs, etc.) to spool sessions

Storing sessions in a central database and/or EJB will work if your clients are not guaranteed to always connect to the same application node in your cluster.

Another approach to consider is using a service such as memcached. This will work in either case.

In general:

Database

• more reliable and will survive an app/server restart
• can be shared across load-balanced servers without having to deal with "sticky" sessions
• slower to access

In-Memory (non-distributed stateful bean)

• Fast storage and retrieval
• Less code
• Will be lost if the app/server restarts

Your choice will be totally dependent on your application requirements and environment. All things being equal, I favor the database solution because of the load balancing and reliability benefits, but this can easily be overkill in many scenarios.

What happens when your app server dies. Is the session state still important? Go for a database.

Do you have more session state, then your server can handle for all the concurrent user? Moving data into a database and pulling only out only what you really need at the moment, might be a solution.

Is your app clustered? If so, the central database makes sure the sessiondata is always available.

Otherwise: Just store it in the session.

Do you have extrem scaling requirements (like stackoverflow or sites with even more traffic)? Find a way not to use the database.

It is true, that the database is often the bottleneck. But a properly setup database should handle a couple bytes of session data just fine. More complex data and queries are what costs performance.

All of the other items are good suggestions. One more is this: Don't use Session state if you don't absolutely need it.

Storing session in a database is (generally) a bad idea for a couple of simple reasons:

1. Typical use of session is to keep from having to load common data from the database server multiple times. If session is stored in the db server then, well, you really haven't accomplished much.

2. Session has to be serialized and deserialized for every single page execution. This means that the session data would have to be retrieved from the server, and written back to the server every single page load regardless of whether you use it or not.

In my experience you are much better served to simply pull the data from your database server when you actually need it. In most cases people put all sorts of short lived data in session simply because they think they are solving a performance problem, when in reality they are making it worse.

Further, if you limit the amount of data down (say to a user id, name, or something like that), then you can store that in an encrypted cookie client side and not have to worry about it at all.

MemCache is one option; but again I'd seriously look at your database usage and see if you can performance tune the queries and schemas first.