This is true.
On the site I last worked on we used a slightly different methodology that
might give Dheeraj some food for thought.
When adding to the shopping basket we displayed the currently available
stock. If this meant that two users simultaneously choose to order 500
widgets (when there were only 500 left) then so be it.
When the user finally decided to "check out" a check would be done against
the available stock. The final order would only be put through if, at this
time, there was sufficient stock available. In the above scenario, whichever
user decided to check out first would get the goods.
We didn't think it was worth stocking people ordering stock at the "let's
put it in the shopping basket" stage because of users putting stuff into
baskets and then not going through with the order, and for the reasons that
Stephen mentions below.
----- Original Message -----
To: "Code Clinic" <proasp_codeclinic@p...>
Sent: Tuesday, August 29, 2000 3:00 PM
Subject: [proasp_codeclinic] Re: concurrency problem
> It seems to me that the issue here is what to do in the long time while
> client is making up his mind whether to buy or not. Record locking as
> is not really the issue, you don't want to stop client 2 buying the
> remaining 25% whilst client1 is doing his shopping. Records should only
> locked whilst an update is taking place, not for the hugely long time that
> a client is viewing a web page.
> I would suggest an extra field to keep a running total of pending
> purchases, possibly even as a child table if neccessary. Some sites
> a client that they then have say ten minutes to buy their goods/tickets.
> You might notify other purchasers that the stock position is fluid.
> Stephen Biggerstaff
> You are currently subscribed to proasp_codeclinic.