Comments

(newest first)

  • lxyscls | Tue, 22 Oct 2019 06:52:52 UTC

    "The most critical factor in implementing the queue, however, is ensuring that the backing persistence is on the same resource as the database. This is necessary to allow the queue to be transactionally committed without involving a 2PC."
    
    I can't get it. Why 2PC is not necessary when the MQ and transaction table are on the same host? 
  • jaogoy | Sat, 28 Jun 2014 07:47:55 UTC

    In my opinion, BASE can not replace ACID, for there is no equality between a big transaction and a group of small transaction split from the big transaction in all situations.
    And the Consistency does not mean Correct, it just meas the consistency of data among many hosts.
    However, It's really a good idea to solve transaction problems in many situations.
  • Toma~ Slivnik | Mon, 22 Apr 2013 11:24:13 UTC

    Are there are any hard guarantees as to when "eventually" is? If there are not, then "eventually" could occasionally mean so long it means an effectively permanent inconsistency, even if in most cases it means "soon". This is a problem especially for truly massive databases where the probability of "eventually" being a very very long time may be tiny, but because there are gazillions of transactions, actually occurs quite regularly. I have seen deployed systems with non-ACID backends where the back end storage would occasionally remain inconsistent apparently permanently and wonder whether that is due to the "eventual" consistency nature of the system or due to a bug in the system elsewhere.
    
    I would be very interested in hearing about any applications (whether real-life or artificial) where ACID really does not matter. I am happy to believe there are some, but I have not seen any that have persuaded me. All the examples that have been offered to me to date I perceived as an attempt to offer a clearly inferior solution and try to argue it was just as good, adequate etc. where in fact it was not.
    
    Financial systems (where it is essential to know account balances in real time) and databases recording threads of interactive instantaneous communication (where communications are generally instantaneous and in the correct order, but are occasionally either delayed or put out of order, can cause real misunderstandings and conflict) in my view are clear situations where a non-ACID back end will be obviously inferior to an ACID one and, where deployed, will result in a clearly inferior and frustrating service.
    
    Are there any situations where it really does not make a difference?
  • Pankaj Kapoor | Sat, 15 Dec 2012 07:16:01 UTC

    A very good article explaining a step by step approach above the advantages and pitfalls. Obviously the article is not aiming to say that you need to replace the SQL by NOSQL. It is totally application dependent. Some data which requires accuracy at the very moment will definitely go for SQL but for very large data NoSQl is a better choice where consistency if eventually obtained is acceptable.
    
  • Winston Pacheco Junior | Wed, 30 May 2012 17:36:49 UTC

    I think a bank is a good example of BASE Systems (I think is the oldest application of this idea), I don't know how this work in your country but in Brazil all the Bank systems are BASE.
    There are ACID transactions, like your Balance (this is ACID, fully consistent), but the "account statement" (I don't know if this is the right term, I wanna say the list of transactions that change your balance like: Supermarket 100,00; Pub 50,00 and so on) are BASE you'll see this data updated only day+1.
    I don't see any problem in this approach and I think the insitutions has no problems too.
  • Juan Trejo | Mon, 19 Dec 2011 20:47:51 UTC

    Think Facebook, Twitter, Amazon... they all use BASE approaches for persistence.
  • Karl Banke | Thu, 28 Apr 2011 15:06:18 UTC

    A rather artifical example as far as I can see. For me, the problem with the argument is the existence of "queues" in each of the datastores that engage in cross system transactions.
    That soon results in a lot of plumbing code or a lot of infrastructure components, since you need (at least) one on every persistent store. In addition one would need some housekeeping on the transaction tracking tables as well, which will diminish performance on the databases. 
  • Sukumar Iyer | Mon, 18 Apr 2011 05:35:12 UTC

    BASE signals won't be good unless connections to file systems
    are pointed out.
    
  • Noman Khan | Sun, 25 Oct 2009 07:14:06 UTC

    I second with Adam D., Marcel. Really a good article to think out of ACID think.
  • Adam D. | Tue, 08 Sep 2009 06:16:33 UTC

    You totally missed the point, Marcel. Not everything should be solved by relational algebra. Take a look at Event Sourcing and Messaging in general. Want scientific? Take a look at Paxos. This is a great article that shows the concepts simply. 
  • michael lazar | Tue, 07 Jul 2009 18:11:49 UTC

    Having designed many distributed systems over the years, this article lays out some good ideas. Obviously, a bank account would not be a good fit for this sort of approach. However, there are many places where eventual consistency is more than sufficient. This depends on business issues not technical issues. Inventory systems, reservation systems, and others all work in most business cases (not all) when they promise eventual consistency versus strict consistency.  
  • Marcel Popescu | Wed, 24 Jun 2009 09:13:32 UTC

    A rather disappointing article to be found in ACM of all places. I'd have expected more rigor here. How much are you improving scalability using this contraption as opposed to algebra (the theory behind relational databases)? How many errors do you have to reconcile, and how soon does that happen? What do you do when you discover that someone withdrew $100,000 twice, out of a $100,000 deposit? In fact, encountering the word "leveraging" made me check the date to make sure this wasn't an April 1st post...
    
Leave this field empty

Post a Comment:

(Required)
(Required)
(Required - 4,000 character limit - HTML syntax is not allowed and will be removed)