Storing a few bits and pieces in a session is all storing a cart will do anyway. While I can see why some folks would consider it a clear benefit to save all carts to the db , i don't. But that can be layered on afterwards, especially with handy packages like beanutils. Given that most the folks who know about these things say the biggest bottleneck is the DB stuff, I'd want to approach this in a manner where i could move stuff around.

When you get to testing you see how many sessions you can have running. The storage of an array of id's would be a nice solution if things start to look bloated, but doing this before would be stamping on problems that aren't there yet. If I had to walk into someone's code i'd prefer if carts had appropriate properties and the products in the cart were also product like.

Cart cart = (Cart) session.getAttribute("cart");
Product product = new Product();
BeanUtils.copyProperties( product , theForm.get("product") );


If i had to pull a bunch of keys and indices from an array I'd be dummy spitting i think.

Cheers Mark

On Thursday, August 21, 2003, at 11:07 PM, Adam Hardy wrote:

I think the issue of using up server memory with lots of shopping carts in the session is worth thinking about. It's just a question of maths - how much memory have you got, what is the peak number of users envisaged, how much stuff are you going to store in the session? even then I think some app servers swap out sessions to the hard drive when memory is low.

You don't need more than an array of item ids and quantities, methinks, so it should be small.

On 08/21/2003 06:38 PM Greg Ludington wrote:
1. Store your cart in session, and when that all works. For everyone. Gets to the checkout and funds are exchanged.
While I agree with the previous posters who said that it would make your
life easier if you can require login, if you absolutely need to save
carts of users regardless of login status, you might consider having
your Cart object impelment
javax.servlet.http.HttpSessionBindingListener. Objects implementing
this interface are notified when they are bound to or unbound from
(either explicitly or by the session itself expiring/invalidated) a
session, and can perform tasks at these times.
In your case, when your Cart object is unbound you would save its
contents to your database. (Conversely, when you first bind a Cart
object to a session, you can check the database and refresh its
contents, if any.) Nothing about this approach prohibits you from
saving Cart information at other appropriate times -- user logins,
purchases, and the like -- this approach just allows you the ability to
store information, like cart contents, at the end of a client session.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to