Yes, BASE and ACID are different concepts, that's why I suggested a direct comparison isn't really accurate. BASE systems would use ACID for persistence to stable storage.
To me the difference really seems to apply more to the application level relationship to persistence than the database's. The database is still going to use ACID transactions for updates to stable storage. The idea of BASE systems is to allow the application to update volatile storage and receive control back immediately, without waiting for the update to be written to stable storage. This opens the door to potential inconsistencies when the data is later written to stable storage, but improves latency. A lot of the system designs that fall into the BASE category also rely on replicated memory for failure handling and load balancing, but this opens another window to potential inconsistencies among replicas (since it's impossible to update all replicas simultaneously). The concept of "eventual consistency" says that at some point these kinds of inconsistencies will be reconciled, and there are a variety of techniques for doing so. None of them guarantee consistency of the stable storage, since there's always a window of time between the update to volatile storage and the update to persistent storage in which interleaving updates can occur, or volatile data can be lost. However, the risk of inconsistency, and the additional effort to resolve them "eventually" once they occur is seen to be worth the improved latency for the majority of cases. The point I was trying to make is that even in the BASE style systems I'm familiar with, ACID transactions are used when the data is (eventually) persisted to stable storage. The concept of BASE just returns control to the application after the update volatile storage, and doesn't wait for the additional time it takes to also perform the update to persistent storage, therefore reducing latency for the application/user. It's a classic trade off, but its discussion seems to have created an over simplification of positioning one against the other, as if BASE were a potential replacement for ACID, which I don't think it is. Good marketing maybe, but not very accurate. Eric On Fri, Jul 17, 2009 at 9:32 PM, Peter Becker <peter.becker...@gmail.com>wrote: > > Eric Newcomer wrote: > > ORM to me is like one of those impossible tasks, like automatically > > converting data types between Java and XML. > I think the latter is actually easier :-) > > > > I think EJB3 is a big improvement over EJB2 and JPA a big improvement > > over entity beans. We are in the middle of mapping JDBC and JPA to > > OSGi BTW and hopefully this will result in more pluggability for > > persistence providers. > > > > BASE is the kind of thing I was referring to in the earlier post in > > that it represents a persistence design based on a different set of > > assumptions. I would not really agree however with a characterization > > of BASE vs ACID, since even in the BASE style systems I'm aware of, > > ACID is still used by the databases when persistence happens. The > > difference seems much more about the decision and timing of > > persistence to stable storage than whether BASE is used in place of > > ACID. AFAIK ACID is still used - if what's meant is 2PC then that is > > probably a more correct comparison, i.e. BASE vs 2PC. > From what I understand BASE and ACID are different concepts. If it is > BASE, it is not ACID -- it doesn't matter if something underneath uses > ACID semantics. If you want ACID at the top, you have to control it all > the way down. BASE is about giving up some of that control in favour of > weaker assumptions. Once you did that, you lost ACID from that layer > upwards. > > Here is the relevant paper: http://queue.acm.org/detail.cfm?id=1394128 > > Peter > > > > On Fri, Jul 17, 2009 at 4:34 AM, Peter Becker <peter.becker.de > > <http://peter.becker.de>@gmail.com <http://gmail.com>> wrote: > > > > > > Rick wrote: > > > I think one of the reasons that relational databases are popular as > > > compared to other solutions is that they map well to the > theoretical > > > tools, such as relational algebra/calculus. > > > > > My problem is that relational databases map to most of the theory > only > > in theory. E.g. SQL does not map to relational algebra, it is more a > > "Based upon a true story" type of thing. I've done this rant a few > > types > > before (including on this forum), but one of the things I really > > miss is > > a true implementation of the relational algebra, which includes > > having a > > proper notion of domains (which could easily be mapped to > OO-classes). > > > For an upcoming e-commerce project I suggested trying out > > couchDB (as > > > promoted by the posse) and sCouchDB (the Scala version of > same?).... > > > and a friend with an architectural leaning asked something along > the > > > lines of: > > > > > > "but can you guarantee atomicity?" > > > > > > which shut me up pretty quickly. > > > > > I believe the ACID vs. BASE question will become more dominant in the > > near future, though. I am somehow afraid that many project will > > pick the > > BASE option when they really need ACID. > > > Disclaimer: I'm a fan of EJB 3.0 > > I've used only JPA, which is really not too bad. They certainly > > seem to > > have learned from the experiences of other products in the area, > which > > is unfortunately not that common with these standards. You still > > need to > > like ORM to like EJB3, though :-) I just find the ORM idea to be too > > much of a neither here nor there thing. > > > > Peter > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
