Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What is the best practice to manage the case where two customers add in the same time a product whose the stock was only 1 ?

Must there be a check in the code of the basket to avoid one of these 2 customers to add the same product ?

Or does this check must be carried out in the payment phase in doing for instance a second query to confirm the concerned product is still present in stock (means not bought yet by the concurrent customer) ?

share|improve this question

5 Answers 5

up vote 7 down vote accepted

There is no perfect answer for this question and all depends on details.

As a first 'defense line' I would try to avoid such situations at all, by simply not selling out articles that low if any possible. If this is possible may depend on the situation and the kind of articles you want to sell. In the company I work, articles are mostly removed from the website before we run out of stock. But we are selling whole sale and the few remaining articles are sold by our sales people as special offers. This may not be an option for small shops, especially when selling high priced articles.

The solution to do the double check when adding something to the basket isn't very good. People put a lot in baskets without ever actually placing an order. So this may block this article for a certain period of time.

So in my humble opinion for small jobs the best way is to do a final check right before the payment, when the order is actually placed. In worst case you have to tell you customer that you where running out of stock right now (what for small shops will not happen that often).

share|improve this answer
    
Well explained :) Thanks –  Mik378 Feb 8 '12 at 12:09

As always, it depends on what your requirements are. If you are Amazon and sell 100,000,000 items per day, the overhead for preemptive checking and locking is probably prohibitive, and the problem of one customer per day not getting their item after all is negligible. It you deal in rare antique religious icons that are unique and expensive, the opposite probably applies. You yourself must know where your business case is located on that spectrum.

share|improve this answer

The best practice, for the user, is obviously to make sure the second add fails. But this is going to slow your whole site down for the sake of the 0.1% case.

The most technically efficient solution, and the one to maximise sales, is to allow it to succeed and then try to fulfil both orders later -- just cause you don't have stock right now, doesn't mean you can't find it in an emergency. If you can't then someone has to contact the user who lucked out and apologise. But that is exactly what led to uproar before Christmas this year (this is not the only article that appeared, so apologies to Best Buy but it was the first I found).

Your job is to present all the options to the business, with pros and cons, and let them decide based on your advice. If they can afford an occasional small hit to reputation to maximise sales then fair enough; if they can't and traffic is so low that you can check for double-updates quickly then that's also their call.

share|improve this answer

I think best practice is to choose which of below options is more appropriate for particular business case:

  1. Optimistic Offline Lock

    ...solves this problem (problem of session conflict) by validating that the changes about to be committed by one session don't conflict with the changes of another session. A successful pre-commit validation is, in a sense, obtaining a lock indicating it's okay to go ahead with the changes to the record data. So long as the validation and the updates occur within a single system transaction the business transaction will display consistency...

  2. Pessimistic Offline Lock
    ...prevents conflicts by avoiding them altogether. It forces a business transaction to acquire a lock on a piece of data before it starts to use it, so that, most of the time, once you begin a business transaction you can be pretty sure you'll complete it without being bounced by concurrency control...
"Whereas Pessimistic Offline Lock assumes that the chance of session conflict is high and therefore limits the system's concurrency, Optimistic Offline Lock assumes that the chance of conflict is low. The expectation that session conflict isn't likely allows multiple users to work with the same data at the same time."

share|improve this answer

This is a people problem, as well as a database problem, the database locking is the easy bit!

Given that a customer may never check out…

You have two basic options:

  • You reserve an item for the customer for a fix time say (20 minutes) after they have added it to the basket – after they time they have to recheck the stock level or start again. This is often used to ticket to events or airline seats.

  • Or you say something like “xxx normal despatched in 24 hours”, but reserve the stock when they checkout, in this case you must allow them to cancel the order after checkout if some items are in stock but not others. (Green, Yellow, Red stock levels can also work well, or some website say “low stock” when they are down to 1 or 2)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.