On 28 Mar 2010, at 06:03, Alexander Uvarov wrote:
> Not every document requires locking. Also, not every application requires to be extremely distributed. Developers can make a decision what kind of application is cooking, in other words, should it scale to thousands of nodes, or just single master with many readers would pretty good.
> The same about transactions, offline replication not ever required. An option to reject on conflict during bulk update would be really helpful (just use single master), but there are obvious problems with sharding coming :(.
I side Robert here. If you figure out that CouchDB doesn't
solve your problems well enough, it might not be the best
fit for your project.
I'm not telling you to go away, but invite you to rethink
what primitives your app needs rather than what you are
used to from other systems and see if CouchDB still
works for you.
It may not and that is just fine :)
Cheers
Jan
--
>
> On 28.03.2010, at 18:40, Robert Newson wrote:
>
>> "I am wondering why not introduce locking in couchdb"
>>
>> It's because locking doesn't scale. The locking strategy you outlined
>> works fine when your database runs on one machine, but fails when it
>> runs on two or more machines. A distributed lock, while possible,
>> would require all machines to lock, which requires them all to be up,
>> and, of course, ten machines are then no faster than one machine. Most
>> distributed locking protocols are blocking (like the usual 2PC
>> protocol), the non-blocking ones are either more overhead (3PC) or
>> more complex (Paxos).
>>
>> CouchDB doesn't let you do with one machine that which won't work when
>> you have ten machines. It's quite deliberately not letting you do
>> something that won't scale.
>>
>> B.
>>
>> On Sun, Mar 28, 2010 at 1:33 PM, Alexander Uvarov
>> wrote:
>>>
>>> On 28.03.2010, at 14:40, faust 1111 wrote:
>>>
>>>> Its sounds like pair of crutches ;)
>>>
>>> Agree with you. Lack of uniqueness, lack of transactions makes couch completely useless for most cases. Solutions like multiple docs with _id as unique key, along with "inventory tickets" sounds insane.
>>>
>>> I invented simple solution with Redis. Just an idea. You can use Redis setnx, msetnx operations to lock desired documents, or just lock "User" by giving this string as key in Redis to lock whole User type. Then just try to lock "User", create your User document, unlock. If there is already a lock, wait and try again. But deadlocks are possible when process that owned the lock is dead and no one can release a lock.
>>> Redis commands: http://code.google.com/p/redis/wiki/MsetCommand
>>>
>>> I am wondering why not introduce locking in couchdb. Couchdb is designed to be extremely fast, but there are also real world problems. Awesome technology, I am crying that such restrictions taking it away.
>