couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Hobson <>
Subject Re: Yet another transaction
Date Tue, 26 Oct 2010 18:04:40 GMT
Hi Ido,

First an observation  - the picker will occasionally go to the picking 
face and find that the stock the computer has just allocated to an order 
is damaged or has been stolen. For these reasons, even if the computer 
is 100% accurate, you will still have a low level of phone calls to the 
customer, asking if the customer wants to back-order or accept a refund. 
(Most people blame the computer for these errors because it does not 

Another factor to consider. HTTP is stateless, so if a customer's 
machine locks up, reboots or loses power while they are shopping, there 
is nothing to tell the server that the shopping cart has been abandoned. 
You need to decide if stock in a cart is sold unless abandoned or timed 
out, or not sold until checked out.

Conclusion - perfection is impossible. You only need a solution that is 
good enough so that it does not significantly add to costs or damage 

I think you will have more success with stock represented as one record 
per stock item, not per stock keeping code. (If you have 20 in stock 
create 20 records).  Then when you sell them, you will either succeed in 
updating the record, or fail, and you can take another and try with 
that. Chose randomly, so that you avoid most conflicts.

Replication will still bite you.  I have seen many approaches tried.

a) Allocate in a central replica, and use local replicas as read-only 
b) Allocate locally and sort out over-commitments when they happen
c) Pre-allocate a small amount of stock to the local replica, and 
replenish this stock very quickly when it is sold.

Generally a) works best but communications costs may make it prohibitive.

Method b) will work acceptably if stock levels are such that stock-out 
conditions are rare.

The two problems with c) are that it raises the minimum stock level of 
slow items unacceptably, and means there is a short period after each 
sale when there appears to be no stock, which results in lost sales.

If live or near live stock levels can be provides, this will help 
methods a) and b). If the customer knows stock levels are low, they will 
be less disappointed if there is no stock at checkout time.



On 22/10/2010 10:40, Ido Ran wrote:
> Hi,
> I know tx question have been asked, but I never got a straight answer. I
> will present an example but I'm afraid that example distract us from the
> main issue which is "what is the new way of changing data?"
> Suppose I have CouchDB in which each document represent item in my
> warehouse. Each item has catalog number and quantity.
> I have agents who sale my items all over town, each agent has smart phone
> and internet access so they can use my great CouchApp :)
> One thing is very important - I don't want agent to sale item I don't have
> in stock and have all the items a client order.
> So one thing is for sure: We can't simply subtract the quantity client order
> from the item document because I might dead-lock myself.
> Client 1 order item Ax5, Bx3
> Client 2 order item Bx3, Ax10
> Suppose I have in stock Ax6, Bx3
> If I handle the two client order at the same time, first Client1 item A then
> Client 2 item B then Client 1 item B then Client 2 item A
> I will get to the last update of item A and find I don't have enough in
> stock, but there is no good way of rolling it back, let's say the buttery of
> the smartphone is dead I now took only half of the order.
> I can create a new document which will represent the order itself. It will
> have all the client detail as well as each item and quantity. Further I can
> create a validation function to allow only order which have all items in
> stock. Does it the way to go?
> Let's say I took the solution of order document, how do I actually process
> the orders and update the quantity of each item?
> I hope I made myself clear, I'm not looking to solve this specific problem
> but understand how to use CouchDB as non-transactional database.
> Thank you,
> Ido
> -----
> No virus found in this message.
> Checked by AVG -
> Version: 10.0.1144 / Virus Database: 422/3211 - Release Date: 10/21/10

View raw message