incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From couchdb user <couchdbu...@gmail.com>
Subject Re: Yet another transaction
Date Fri, 22 Oct 2010 15:05:57 GMT
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,
>>
>

Mime
View raw message