views:

879

answers:

3

I know the general consensus for information like shopping cart items is to store them in session. But what about objects that belong to a user that can be altered by other users? Say, for instance, an eBay-like site. If you store a user's "items" in session, which contain the current bid amount, and another user comes in and places a bid on that item, you would have to update both the item in the database as well as the item in session, wouldn't you?

In cases like these, are the only options to store in session and refresh whenever any action another user takes affects a person's session values or store everything in the database and retrieve it every time (could get expensive if, say, you have the bids displayed on the side panel of every page).

+5  A: 

I would store it all in the database and retrieve it everytime. Depending on the volatility of the data caching for a few seconds may be in order. The biggest problem is keeping the two consistent.

I think that it isn't as expensive as you think to retrieve the data every time. Databases are very efficient if you are looking up based on a key. I'd err on the side of simplicity (store in DB and retrieve) until performance problems show up under load (ie in Load Testing).

If there is only going to be a handful of times, you may be able to use the Application Cache (unless you have more than one worker process/server) and make sure the DB and cache stay in sync.

Robert Wagner
+4  A: 

I would personally store it in a database. Firstly, because your data is a lot safer there, and it makes it easier to share in the case where you need a web farm. Also, you don't need to have the data on every page. Just when the user goes to the shopping cart. The other plus of storing it in the database is that you can analyze later, the stuff that people are adding to the cart, but not actually purchasing.

Kibbee
A: 

How to store multiple items added to cart with multiple quantities in session in Rails?

Rup