Talk:Multiversion concurrency control

message: Merging is impossible! MVCC is a different term it, there are many MVCC systems but only few are integrated with timestamp CC. Many of them are working with two-phase locking (2PL) to reduce shared-locks.
----
There are at least two kinds of MVCC using 2PL (Oracle merged, Postgres) and using timestamps (also Oracle?). One can say that MVCC extends both CC methods to eliminate read limits. Also pure timestamp CC does not store versions but only detects conflicts based on timestamps and restarts transaction.
source1
source2
--Adie 20:16, 3 August 2005 (UTC)
replies: text: Agreed. I've made the change. Personally, I think this article is more technical than it needs to be. Perhaps use the first (and only paragraph) from the other page, plus the last from this one? Turnstep 23:34, 26 October 2005 (UTC)
thread_title:  Merging 

message: The transaction processing system I developed on Cm* (CMU's 50-way multi-microprocessor) for my thesis research in 1981 used multi-version pages to provide a most-recent-snapshot mechanism for queries.  This was not the main emphasis of the work, although there were some new features, including: garbage collection of old versions of pages at the earliest point at which it could be guaranteed they would no longer be needed, based on the minimum value of a WPCL (write-phase completion list - the write phases of multiple transactions could be simultaneously in progress).  This was done efficiently by maintaining a garbage list, which was a list of (version number, version set) pairs.  The best documentation is my thesis, Design of Concurrency Controls for Transaction Processing Systems, CMU 1982 (still available, I notice, via ACM's digital library, and probably elsewhere - see section 6.4 for more details on the garbage list structure).  There is some discussion of design philosophy supporting this approach as well (e.g. see Figure 1.1 page 3).  Bernstein/Goodman and Reed are referenced (of course, along with all other related work of which I was aware); however the Prime system was not referenced in my thesis since I didn't know about it.  I found out about the Prime system later, and referenced it in my paper Separating Policy from Correctness in Concurrency Control Design, Software - Practice and Experience, Vol. 14(9), 827-844 (Sept. 1984).  One reference for the Prime system is the following (unfortunately I no longer have a copy):
D.J.DuBourdieu, Implementation of Distributed Transactions, Proc. 6th Berkeley Workshop on  Distributed Data Management and Computer Networks, UC Berkeley, Feb. 16-19, 1982.
Above comments submitted by John T. Robinson
Jtrbnsn 19:46, 24 January 2007 (UTC)
replies: text: Thanks for submitting this. I have access to the Digital Library and I'll try to remember and look up the reference when I have more time. --Craig Stuntz 21:19, 24 January 2007 (UTC)
thread_title:  Further History and Comments; Prime System Reference 

message: The Wikipedia article for "timestamp", which is cross-referenced here, is about a cryptographic concept that seems different than a transaction timestamp.  Perhaps the cross-reference should be replaced by something else?  192.127.94.7 19:53, 15 February 2007 (UTC)
thread_title:  timestamp 

message: The links to 'netezza' and 'greenplum' seem like advertising spam here to me. I don't think either commercial product is especially notable in the context of MVCC - particularly as they are Postgres derivatives. So I'm going to remove them.  —Preceding unsigned comment added by 93.97.25.15 (talk) 15:02, 8 August 2009 (UTC)
thread_title:  postgres derivatives 

message: How could an article like this don't mention this guy ??
Interbase was the first commercial product to use MVCC.
And firebird is a fork from Interbase.So it always had MVCC too.  — Preceding unsigned comment added by 201.21.99.219 (talk) 23:52, 21 March 2012 (UTC)
thread_title:  Jim Starkey / Interbase 

message: This line in the Implementation section is contradicting the example and does not seem to characterize an MVCC:
If a transaction (Ti) wants to write to an object, and if there is another transaction (Tk), the timestamp of Ti must precede the timestamp of Tk (i.e., TS(Ti) < TS(Tk)) for the object write operation to succeed. Which is to say a write cannot complete if there are outstanding transactions with an earlier timestamp.
Should it say about Tk that is another write tx?
Lucian.ciufudean (talk) 08:49, 9 May 2012 (UTC)
replies: text: Well, it's already implied. A row version can't have a transaction timestamp unless it was written! The important fact isn't that Tk is "a write transaction"; the important fact is that it wrote to that specific object. --Craig Stuntz (talk) 20:47, 10 May 2012 (UTC)
thread_title:  transactions 

message: Shound scientifical papers be separated from implementation references ?  — Preceding unsigned comment added by 92.158.201.227 (talk) 12:43, 10 March 2013 (UTC)
replies: text: Probably. The usual method of doing so is by renaming the current "References" section to "Notes". Then starting a new section again called "References" and put the scientific publications there. And finally, change the footnotes that reference scientific publications, to only mention the authors, year and possibly page number, so people will know they can find them in the "References" section. —Ruud 13:20, 10 March 2013 (UTC)
thread_title:  References & Papers 

message: Current version of the doc says
"MVCC fails to achieve true snapshot isolation contrary to what the original paper was assuming. Under some circumstances some anomalies can arise called skew write and read-read anomaly"
This is misleading because skew write anomalies are a known problem that can occur in snapshot isolation. What is meant by "true snapshot isolation" here?
171.65.239.131 (talk) 22:47, 16 September 2013 (UTC)
replies: text: I have removed the challenged assertions. --Chris Purcell (talk) 22:21, 7 January 2015 (UTC)
thread_title:  Relationship between MVCC and Snapshot Isolation 

message: The current version of the article says:
MVCC uses timestamps (TS), and incrementing transaction IDs (T), to achieve transactional consistency. MVCC ensures a transaction (T) never has to wait to Read a database object (P) by maintaining several versions of such object (P). Each version of the object (P) would have both a Read Timestamp (RTS) and a Write Timestamp (WTS)
but then continues with 
which lets a transaction (Ti) read the most recent version of an object (P) which precedes the transaction's (Ti) Read Timestamp (RTS(Ti)).
My understanding is that transactions only have a generic timestamp. In the above sample, perhaps a better version would be something like:
which lets a transaction (Ti) read the most recent version of an object (P) where the object's Read Time stamp precedes the transaction's Timestamp (RTS(P)<TS(Ti)).
This is a problem through the whole article.  — Preceding unsigned comment added by 162.221.47.135 (talk) 19:18, 4 March 2016 (UTC)
thread_title:  RTS and WTS of objects vs timestamps