Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of ido.ran@gmail.com designates
 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=cwGF1ewbZFMhDLyVYufNF/k7wMKUO4m0Ii5zLQMjLrScu2c6BWIhMUFmg3lhLfB2Rh
         kW+jB+OIt8gvx8AyIZl8zxiUFe8xnxSQfPmuWFS/KalwujYKHGSabVe8/PZVkji9S4PU
         iZ4rs65swHel0TxcBDCX8doq5iqepbkhAkMto=
MIME-Version: 1.0
In-Reply-To: <AANLkTinoE6-JmT5AWFZiBbu7ZDy3nJYWLiXeydbbmZbZ@mail.gmail.com>
References: <AANLkTine7ms1m_EDp=4c4eBrQkg3KqEwd+-=_7STD5nO@mail.gmail.com>
 <AANLkTikQhBB=Qy251prvjeTC5x145JzDndyosgyzguGv@mail.gmail.com>
 <AANLkTimDm3f3KycQQCs1Abtv18Y0SCWMOYm9Y7kjm47i@mail.gmail.com>
 <AANLkTinoE6-JmT5AWFZiBbu7ZDy3nJYWLiXeydbbmZbZ@mail.gmail.com>
From: Ido Ran <ido.ran@gmail.com>
Date: Sun, 24 Oct 2010 13:37:07 +0200
Message-ID: <AANLkTikJGFusghh_+kc6h95gtoUyEa+4mw9NeziNkLXv@mail.gmail.com>
Subject: Re: Yet another transaction
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf303bfff0d936dd04935b4c72

--20cf303bfff0d936dd04935b4c72
Content-Type: text/plain; charset=UTF-8

Hi,
If I generalize your suggestion (and correct me if I'm wrong) the
application should be handle conflicts because it is not possible ignore
them and make sure they will never exist.
I guess if google did not find generalized way to handle replication
conflicts nor do CouchDB can, but what we (as community) can is provide
"Best Practice" or guideline and set of examples of how to handle both
"non-transactional changes conflict" and "replication conflict".

Does it make sense?

On Fri, Oct 22, 2010 at 5:05 PM, couchdb user <couchdbuser@gmail.com> wrote:

> 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
> good
> > point that we can "close" the circle, that is deduct the quantity, when
> the
> > 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>
> wrote:
> >
> >> 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
> 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
> >> >
> >>
> >> 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.
> >>
> >>  Regards,
> >>
> >
>

--20cf303bfff0d936dd04935b4c72--