Last I checked MySQL/InnoDB doesn't seem to use MVCC, at least that's certainly the impression I get from using it where locks are frequently left hanging leading to transaction timeouts that are frequently solved by a database server restart, it's one of my many many many problems with MySQL.
Alex On Thu, Jul 23, 2009 at 5:58 AM, Reinier Zwitserloot<[email protected]> wrote: > > Am I missing something? > > Postgresql, MS SQL Server, H2, MySQL/InnoDB, Oracle, and even CouchDB > - *ALL* use MVCC to implement transactions. > > That's easily over 90% of all transactional db usage in the world. > > http://en.wikipedia.org/wiki/Multiversion_concurrency_control > > > On Jul 23, 8:39 am, kirk <[email protected]> wrote: >> Alex Turner wrote: >> > Guess you've never heard of MVCC? >> >> I have. but putting it into practice is a wee bit difficult. You >> typically end up with a big "point in time" abstraction mess. >> >> Regards, >> Kirk >> >> >> >> > On Mon, Jul 20, 2009 at 1:05 AM, kirk<[email protected]> wrote: >> >> >> Hi Steven, >> >> >> Just got back from vacation and this thread jumped out at me and maybe I >> >> jumped in a bit early. Now that I've read more of the discussion.... >> >> >> I'm not a historian also but my experience with hierarchical is that >> >> they were limiting in what you could model with them. This wasn't a >> >> problem with network dbs. The problems you've pointed out with >> >> hierarchical I've not found with network db. But then my experiences >> >> with them are limited and fairly old. I'll focus on the tooling thing >> >> 'cos I think that it's the most important mention in your response. >> >> >> I worked with OO databases for a number of years, first as a user and >> >> then as an employee of GemStone. When I first ran into them the project >> >> rejected them because of the schema migration problem (object >> >> versioning). It appears that RDBMS gives you a huge win with schema >> >> migration even though it suffers from the same problem. One of the big >> >> differences is, the data model has been abstracted away from the code >> >> (anti-OO). This allows DBA's to be draconian in allowing changes to the >> >> db schema without affecting app developers too seriously most of the >> >> time. Investment in RDB tooling is such that schema migrations are less >> >> painful. OODB didn't have the time to get these tools into the market >> >> place and they seriously needed them as restricting schema in OO is a >> >> serious restriction to place on the developers. Obviously Hierarchical >> >> and Network technologies suffered from the same lack of funding as >> >> investment in relational sucked up all the capital. >> >> >> The other comment that struck a cord was one in the initial email >> >> suggesting that in order to make a DB scale one had to front it with a >> >> big cache. This was suggested to be an indication of a problem. I'm not >> >> sure that I agree that it's an indication of a problem to the point >> >> where we need to throw the baby out with the bath water. After all, >> >> caching is used every where you'd like to short-circuit a call path. >> >> Think CPU cache short-circuiting a call to memory. What it does suggest >> >> is that we need to seriously think about how we are using the technology >> >> and recognizing that the A in ACID equates to a big fat lock that using >> >> current practices results in *every* thread in your system.. in your >> >> cluster... in your server farm pass through it. If we want to increase >> >> concurrency in our systems, adding a big fat lock that every thread must >> >> pass through doesn't seem like a wise thing to do. However, just as RAM >> >> is still useful, so it relational persistence technology. We just need >> >> to learn how to use it to build the types of systems we are building >> >> today, not the ones that we built yesterday. >> >> >> Regards, >> >> Kirk >> >> >> Steven Herod wrote: >> >> >>> I'm not a historian, and I acknowledge that a better theory can be >> >>> ruined by a crappy implementation but what I've noticed over the past >> >>> 2.5 years hanging around a mainframe hierarchical db is that it takes >> >>> a COBOL programmer and hours, weeks or months for questions/changes >> >>> like the ones below to be dealt with: >> >> >>> 1. Can I get the structure of the database? >> >>> 2. Can I get a copy of the data in this table? >> >>> 3. Can we increase the size of this column by 5 chars? >> >>> 4. Can we increase the number of addresses we can store? >> >>> 5. Can we find out what the distinct values of this col are in this >> >>> table? >> >>> 6. Can you tell me how many customers we have which own <this >> >>> product>? >> >> >>> Obviously each of these things can be done in seconds in SQL and with >> >>> freely available inexpensive tooling. >> >> >>> We also have issues with data quality. Lack of constraints and >> >>> foreign keys... it catches up with you after 20 years of data >> >>> collection :). >> >> >>> I'm in the process of reading the Amazon Dynamo paper, very >> >>> interesting, but it strikes me again that its a very, very specific >> >>> type of problem, something that isn't appropriate for a vast number of >> >>> businesses who process data. (Just as a RDBMS isn't appropriate for >> >>> Amazon). >> >> >>> On Jul 20, 7:10 am, kirk <[email protected]> wrote: >> >> >>>> Steven Herod wrote: >> >> >>>>> I think you might be overlooking how revolutionary SQL/Relational >> >>>>> storage is compared to what came before it. >> >> >>>> like hierarchical and network databases? >> >> >>>> Seriously, of the 3 types of databases.. network was by far the best but >> >>>> least understood by decision makers so we're stuck with Relational. >> >> >>>> Regards, >> >>>> Kirk > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
