From: Alex B. <boi...@in...> - 2006-02-16 23:46:16
|
Serializability is more about how strict you are when doing conflict analysis. To have total ordering (aka serializability) you must enforce that the read and write set of a transaction are completely disjoint from the write set of any transaction committed after the transaction started. alex 'Kevin Day ' wrote: > Alex- > > Maybe you can help - can you explain to me how MVCC could have > anything to do serializability of transactions? Am I completely > off-base in saying that adding read locking to MVCC would defeat the > purpose? > > I'm obviously having a massive disconnect. > > Thanks, > > - K > > > > > > Kevin, > > MVCC does provide serializability. The tradeoffs among correct > concurrency control mechanisms involve performance not correctness. > The problems with performance for MVCC are that, by itself, it tends > to produce more transaction restarts and lower overall transaction > throughput when compared to 2PL. Postgres is some sort of hybrid > of 2PL and MVCC. I tried their chat group yesterday to get some > insight into exactly what kind of a hybrid, but no one could say "Oh, > we implemented XYZ". > > I do not think that MVCC (or any hybrid of MVCC) is a silver bullet > for performance. Neither postgres nor Oracle is a clear performance > winner -- in fact I have personal experience with the one of these > platforms which places it an order of magnitude slower than jdbm for > our application (an semantic web store) using a solution developer by > the database people themselves. > > I recommend a closer reading of this paper. I have found later articles > which use analytic techniques to examine the performance of a variety of > concurrency control mechanisms, but none which benchmarks real databases > explicitly in terms of this issue. Perhaps we could look at some of the > RDBMS benchmark literature for some insight there? > > Enjoy your vacation, > > -bryan > > -----Original Message----- > From: jdb...@li... > <mailto:jdb...@li...> > To: JDBM Developer listserv > Sent: 2/16/2006 4:48 PM > Subject: re[2]: [Jdbm-developer] MC-DataSafe > > Bryan- > > Can you please provide a description of how MVCC (with non-serialized > processing of transactions) would cause either of the two lost data/bad > data examples described in the paper? > > The way I read your email, it sounds like you are implying that MVCC > can't provide transaction isolation or atomic updates, when it > absolutely does. MVCC just operates optimistically in these situations. > Under MVCC in the first example, an abort would occur. In the second > example under MVCC, the report created in T2 would be correct, and T1 > would commit without problems. In either case, nothing gets left on the > floor... > > The massive advantage of MVCC comes in the second example: If the > report required a significant amount of time to complete (it was reading > a huge number of rows), then serializing the transactions as described > in the paper will cause massive slow downs for the poor sucker who is > trying to execute T1 (and kill concurrency). In MVCC, the update would > happen immediately and return, even if T2 takes a long time to complete. > This absolutely maximizes concurrency, and is perfectly safe. > > > I'm going to need some serious convincing with concrete examples before > I'm willing to favor serializable transactions over MVCC's approach. My > concern at this stage is that much of the literature on these topics > either doesn't account for the radical departure from the norm that MVCC > is, or it is incorrect in it's description of how MVCC actually operates > in practice. > > I actually find it humorous that the concurrency control paper we are > talking about here says that "the problem for nondistributed DMBSs is > well understood... and one approach called two-phase locking has been > accepted as a standard solution." That may have been true in 1981 when > the paper was published, but the good folks at PostgreSQL and others > have pretty much blown that out of the water. > > This means that any broad claims made in these older papers have to be > taken with a considerable grain of salt, and evaluated in the context of > the new development of MVCC. Bernstein and Goodman are certainly going > to say that 2 phase locking is the only way to go - they weren't even > aware that a better approach was possible. > > Anyway - I'm going to be gone until the 28th - hopefully you and Alex > can continue the discussion with vigour while I'm gone! > > Cheers, > > - K > |