From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com> - 2006-02-16 18:46:42
Niggly point. A single tx will only produce one version no matter how many
times the tx writes the datum before the commit.
Scenario 1 - this is what happens with NO concurrency control, not even a
copy on write mechanism.
Scenario 2 - this is achievable with a copy on write model also. Nothing
Scenario 3 - This is clearly non-serializable. Both tx start with the same
observed value D0 and update to distinct value. There is no way that these
two transactions can run concurrently.
I don't think that these examples sort out MVCC from other schemes for
concurrency control, but maybe that is not the goal?
From: jdbm-developer-admin@... on behalf of Alex Boisvert
Sent: Thu 2/16/2006 11:43 AM
To: Kevin Day
Cc: JDBM Developer listserv
Subject: Re: [Jdbm-developer] Sample MVCC transaction flow
PS: As seen in the movie "Catch Me If You Can" :)
Kevin Day wrote:
> Hi guys - I've put together a quick flow of a couple of transactions
> under MVCC and non-MVCC concurrency control. I'm hoping this will
> help to clarify why reads never block writes (and why writes never
> cause reads to abort) in MVCC.
> Please let me know if you have any thoughts/comments - or if you think
> I missed something important.
> - K
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
Jdbm-developer mailing list