Maintaining state in the application server or in the database?

Question

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?

Answer 1

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.

Answer 2

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.