EJB performance

"Chris Hatton" <christopherhatton@hotmail.com> wrote:
>I'm implementing a ShoppingCart system using an application server, and
am
>going with the ShoppingCartBean as a stateless session bean.
>
>My question is: How should I handle the ShoppingCartItem?
>
>My options (so far)...
>
>1) Use entity beans. But, if I make it an entity bean, won't I risk running
>out of memory for an active site? I assume there's some maximum number
of
>beans, at which point performance will really begin to suffer.
>
>2) Hit the database a lot. What are the performance implications here if
I
>have to access the db twice everytime I add an item to the cart? (once
to
>view details, once to add to cart)
>
>3) Use the HttpSession (most likely ShoppingCartBean) to cache items that
>are in the cart and items that have been looked (just in case they may go
to
>the cart). Only one db access!.
>
>Any suggestions from someone who's already beat this one would be greatly
>appreciated!
>
>Thanks!
> Chris Hatton
>
>
>
My Feeling with all the above options is that Database access is a relatively
low cost operation and is probably the most efficient option.
Stored procedures will also help to improve performance on the server side
of things.

You could use a cookie to cache the cart detail on the users machine. That
would let you lose one of your database calls.

If you are going to add the item to the cart then display the details to
the user. You could eaisly write a stored procedure that would allow you
to do all that in one database call.

You're right Prakash, the whole point of the shopping cart is to hold the
items outside the database until the user decides to go to the check out.
At this point, the user may delete some items or may just leave the shopping
cart and walk away. The shopping cart should not be written to the database
until the user checks out. If the user never gets to the checkout, or just
abandons the session, the shopping cart can be written to the database as
a pending selection so it's available next time the user logs in.

"prakash" <prax_us@yahoo.com> wrote:
>
>The idea of updating the database evertime user adds an item into shopping
>cart is, I think, not efficient. I think database should be updated when
>the user has completed the shopping(checked out for payment). Till then
this
>kind of information can be stored in some kind of data structure or some
>collection.
>"Chris Patterson" <cpatterson@nc.rr.com> wrote:
>>
>>"Chris Hatton" <christopherhatton@hotmail.com> wrote:
>>>I'm implementing a ShoppingCart system using an application server, and
>>am
>>>going with the ShoppingCartBean as a stateless session bean.
>>>
>>>My question is: How should I handle the ShoppingCartItem?
>>>
>>>My options (so far)...
>>>
>>>1) Use entity beans. But, if I make it an entity bean, won't I risk running
>>>out of memory for an active site? I assume there's some maximum number
>>of
>>>beans, at which point performance will really begin to suffer.
>>>
>>>2) Hit the database a lot. What are the performance implications here
>if
>>I
>>>have to access the db twice everytime I add an item to the cart? (once
>>to
>>>view details, once to add to cart)
>>>
>>>3) Use the HttpSession (most likely ShoppingCartBean) to cache items that
>>>are in the cart and items that have been looked (just in case they may
>go
>>to
>>>the cart). Only one db access!.
>>>
>>>Any suggestions from someone who's already beat this one would be greatly
>>>appreciated!
>>>
>>>Thanks!
>>> Chris Hatton
>>>
>>>
>>>
>>My Feeling with all the above options is that Database access is a relatively
>>low cost operation and is probably the most efficient option.
>>Stored procedures will also help to improve performance on the server side
>>of things.
>>
>>You could use a cookie to cache the cart detail on the users machine.
That
>>would let you lose one of your database calls.
>>
>>If you are going to add the item to the cart then display the details to
>>the user. You could eaisly write a stored procedure that would allow you
>>to do all that in one database call.
>>
>