I am creating an ecommerce application using CSLA. One of the requirements of this application, is that purchasable items are highly customizable. Of course, the user's selections must be stored in a database for future processing. As with any ecommerce applications, many of the orders will be abandoned. The "order items" are stored in a CSLA editable collection.
My question is this -- Would it be appropriate to bind my .NET controls (and CSLA objects) to the session, rather than directly to database tables? The session would be persisted in SQL Server, to avoid memory/scalability issues. The objects would only be transferred from the session to the main database when the shopping cart is processed. I am hoping that this process would reduce my need to create "cleanup" procedures to purge data collected from abandoned shopping carts?
Before I spend a lot of time creating code to support this process, I wanted to toss the idea out there to see what other people think. Is there a simpler approach that I am not considering? Has anyone tried anything like this?
Thanks in advance.
RJ
RJ
The answer is, it depends.
It's actually more of a scalability issue. If you expect a high amount of concurrent users, storing your object tree in session will decrease your scalability. However it will improve the performance for each user.
If you know that the amount of concurrent users isn't that high there is no problem in storing your object tree in session, though I will recommend that you strip it down to what is absolutely necessary.
On the other side, if you know you'll have a lot of users I'll recommend that you store it in the database. You can either use sql-session state or allow saving the object tree directly to your commerce database, with a flag that indicates whether the purchase is completed or still in progress. Of course you may want to delete this again if the user discards the shopping cart (leaves the site).
One advantage of storing the "in-progress" shopping cart in your commerce database is that it can be persisted between visits just like the Amazon shopping cart.
If you choose to store the shopping cart in your commerce database you may want to create a seperate set of tables for "in-progress" carts, if your transaction-rate is very high. Inserting and deleting "in-progress" carts in the "completed" cart tables can put a toll on your database.
Hope this helps
/Henrik
Thanks for the response.
I am expecting a high number of concurrent users -- at least I hope so. :)
I did also consider setting a status flag and I may go that route. The main reason that I considered storing this information in the session is that I could leverage .NET's ability to "cleanup" old session data. If the session were persisted in SQL Server would there be any scalability issues if I allowed the session to live for a long time (a day, a week)?
I'm starting to think that I should abandon this approach and use the more conventional approach of deleting "abandoned" records.
RJ
RJ
I would not go the route with sql-session state if you expect a high number of transactions. It will not only be your shopping cart but all session state that will be serialized to the database and unless you have a seperate database server to handle this, your commerce database will have enough work to attend to besides storing and retrieving session state.
If you decide to store it in session state you should use an external state server with an abundance of ram. The problem with this approch though, is that you don't know when a user ends his or her session and will have the cart in there until the session times out. Of course you can set a short session timeout but that can cause alot of other problems if your users are "slow". I use this approach in a couple of my systems, where I have set the session timeout to 2 minutes. Along with that I have build a webservice with a "HeartBeat" method, that keeps the session alive as long. This webservice is called every minute from client script using "Atlas/AJAX". It works pretty well.
My preferred method though is to actually store the shopping cart in the commerce database. I have set up a job on the database that clears orphaned shopping carts that are more than a day old. Each shopping cart has a "Persist" flag, so the user can choose to store the shopping cart until the next visit.
/Henrik
Good point on the serialization problem. I thought of another reason why this is a really bad idea. I would not be able to take full advantage of the "IsDirty" flag on the business object. The session-base approach would also be far less extensible. I guess I just got a creative bug, without really thinking things through.
Thanks again.
RJ
Copyright (c) Marimer LLC