Announcement

Collapse
No announcement yet.

Update Basket Item Prices and Availability Mid-Session

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Update Basket Item Prices and Availability Mid-Session

    We're finally updating our sites to use "inventory at checkout" and I'd like to extend the basket timeout to possibly several days or even a week for one of our stores. How often does the basket update pricing or check inventory availability in this type of scenario?

    Also, are there any significant downsides to this that I should consider when determining how long to set this?

  • I've done exactly that with my store. I now have baskets set to expire after seven days. I can't speak to updating pricing since my prices are static, but the basket checks contents vs. available inventory during the checkout process--I think just before payment is required. So it works like a charm when someone puts an item into a basket but delays checking out and then returns a few days later to do so after inventory is all gone.

    I did encounter one issue when I made the change you are considering. When this case occurs, the user is directed back to the basket page and there is an error message that is shown. In my case, for some reason, the error message was not being displayed. So to the user it seemed like an odd loop that wasn't letting them check out because they weren't getting the information that the item was out of stock and that they needed to remove it from their basket before proceeding. I fixed this (I don't remember what I had to do now, but it was easy), and it's fine now. But be sure to test for this so you don't have the problem I did.

    The only downside of extending basket timeout significantly is that your number of baskets will balloon--possibly into the tens of thousands. But if you have system resources available for this, it won't be an issue. Make sure you are deleting expired baskets with a scheduled task.
    Todd Gibson
    Oliver + S | Sewing Patterns for Kids and the Whole Family

    Comment


    • Hi Josh, on high traffic sites, the long basket timeout, combined with certain code and/or third party modules, can sometimes lead to trouble. The issue is that when running long basket expiry, the baskets-related database tables can grow significantly because bots, hackers, etc. that scan a site will often scan store pages, but not send cookies back with subsequent requests, so you end up with a new session for each request, which results in very large numbers of sessions being kept. Some modules and/or code that's been added may do things against the basket table which result in a full table scan at the database level, which is an extremely slow query relatively speaking. Other queries that need access to the baskets tables will block while the long ones run, and that can result in site availability issues.

      We've got someone working on a customization to combat this issue by regularly looking for, and removing, small batches of baskets which have no products associated with them, and are not a logged in customer. There's no harm in those baskets going away because a new one would just be created on the next request if it were actually a real shopper. In theory, this will keep the baskets count down since only legit shoppers' baskets would remain to the expiry you've set.

      If you shoot me an email I can give you more info.
      David Hubbard
      CIO
      Miva
      [email protected]
      http://www.miva.com

      Comment


      • Thank you both. This is great information.

        Comment


        • Originally posted by ILoveHostasaurus View Post
          Hi Josh, on high traffic sites, the long basket timeout, combined with certain code and/or third party modules, can sometimes lead to trouble. The issue is that when running long basket expiry, the baskets-related database tables can grow significantly because bots, hackers, etc. that scan a site will often scan store pages, but not send cookies back with subsequent requests, so you end up with a new session for each request, which results in very large numbers of sessions being kept. Some modules and/or code that's been added may do things against the basket table which result in a full table scan at the database level, which is an extremely slow query relatively speaking. Other queries that need access to the baskets tables will block while the long ones run, and that can result in site availability issues.

          We've got someone working on a customization to combat this issue by regularly looking for, and removing, small batches of baskets which have no products associated with them, and are not a logged in customer. There's no harm in those baskets going away because a new one would just be created on the next request if it were actually a real shopper. In theory, this will keep the baskets count down since only legit shoppers' baskets would remain to the expiry you've set.

          If you shoot me an email I can give you more info.
          Hi David -
          We've historically kept a very short expiration period (like 2 hours). Do you think going to 1 full day would cause the potential issues you've described above? And, if so, is that customization something available to all or is it a module for purchase?

          Thanks,
          Paul
          Paul

          Comment

          Working...
          X

          This website uses cookies to identify visitors, track visitors to our website, store login session information and to remember your user preferences. By continuing to use this site you agree to our use of cookies. Learn More.

          This website uses cookies. By continuing to use this site you agree to our use of cookies. Learn More.

          Accept