Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of couchdbuser@gmail.com
 designates 209.85.210.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=XSOMkLAMDAHgMuiv3xnPMnrunD5hh4wNF46CjDVZ6T2/3E+cLFgQA1i0Z3IDZeDtvy
         PQxMddooB8u0f8MY1dsM0/RX8Fo4l/CezjeDoOPdfmoxfqub1CfIw07OKjFDVOy6JXFB
         zp2T5nN5TW8HHySxhwitFf249x/Ds7j8U7AlA=
MIME-Version: 1.0
In-Reply-To: <AANLkTimDm3f3KycQQCs1Abtv18Y0SCWMOYm9Y7kjm47i@mail.gmail.com>
References: <AANLkTine7ms1m_EDp=4c4eBrQkg3KqEwd+-=_7STD5nO@mail.gmail.com>
	<AANLkTikQhBB=Qy251prvjeTC5x145JzDndyosgyzguGv@mail.gmail.com>
	<AANLkTimDm3f3KycQQCs1Abtv18Y0SCWMOYm9Y7kjm47i@mail.gmail.com>
Date: Fri, 22 Oct 2010 11:05:57 -0400
Message-ID: <AANLkTinoE6-JmT5AWFZiBbu7ZDy3nJYWLiXeydbbmZbZ@mail.gmail.com>
Subject: Re: Yet another transaction
From: couchdb user <couchdbuser@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ido,

On Fri, Oct 22, 2010 at 9:31 AM, Ido Ran <ido.ran@gmail.com> wrote:
> Hi,
>
> Thank you for the answer.
> You are suggesting to use the "order is a document" approach. You have go=
od
> point that we can "close" the circle, that is deduct the quantity, when t=
he
> order status is changed from "created" to "approved".
>
> This is good. Now let's bring replication into the picture.
> Is it possible that due to replication delay a order which
> is perfectly valid in one database will be invalid due to changes made in
> another database?
> For example, two agents make a sale at aprox. the same time of the same
> item. They are working in different cities (and let's say each city has
> replica of the database). The each checkout and all is well but together
> they sold more item we have on stock.
>
> I'm not trying to show there are design that do not work well, I'm trying=
 to
> understand how to design a system that will work with the replication and
> optimistic locking, not against it.
>

Replication is an interesting aspect, I'm trying to think of a clean
way and I'm not sure ... this is what I have come up with so far:

If your application layer checks every replica during checkout, well,
that just defeats the purpose of replication :)

How about having a process, like a cron job, that would run once a
minute, looking for conflicts of this kind? if it finds that two or
more sales reps. sold the same item, it sends some kind of
notification explaining that the items are not available any more.

Something that may alleviate or reduce upset customers is that at the
time the sales rep. takes the order, tell the customer how many items
you have in stock, if most orders are for, let's say, 10 of each, and
you have 11 in stock, there is high changes your order will have
issues,. but if you have 1000 in stock, it may be very unlikely that
all your sales people will sell the same item right that minute.

Another idea, if you find the conflict situation too often, maybe you
can have your sales team tell customers that orders are not
"completed" until they sync up. In this way, they will all know that
from the time they place and order, there is a delay before it gets
"confirmed".

Regards,


> Thanks,
> Ido
>
> On Fri, Oct 22, 2010 at 2:49 PM, couchdb user <couchdbuser@gmail.com> wro=
te:
>
>> Ido,
>>
>> see comments below:
>>
>> On Fri, Oct 22, 2010 at 5:40 AM, Ido Ran <ido.ran@gmail.com> 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 t=
he
>> > 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 ph=
one
>> > 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 i=
n
>> > stock, but there is no good way of rolling it back, let's say the butt=
ery
>> 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
>> >
>>
>> How about moving the checks to the application level?
>>
>> Your sales team uses something like a shopping cart, as they add items
>> to the cart, you check the stock of each item, if you have enough, go
>> ahead with the order, otherwise, return an error.
>>
>> Those items do not deduct stock, because the order is in "created"
>> status. Once the sales rep. took all the items, he needs to
>> "checkout", at which point your application can check if you still
>> have enough of all those items, if true, the order goes to another
>> status, which will also mean you are deducting stock.
>>
>> There may be some flaws with this design, but maybe it works just fine :=
)
>>
>> Let me know if you have any questions.
>>
>> =A0Regards,
>>
>