Re: Idea for concurrent transactions

Quoth hantheman12_at_hotmail.com (hantheman):
> Todays databases use locking or some optimistic approach. The first
> one is suspecticle to dead locks and heavy locking overhead in
> distributed scenarios. The second one leads to problems with hot spots
> and cascading aborts.
>
> One approach I haven't seen discussed much is this:
>
> 1) Each transaction read objects (or rows or entities - whatever you
> prefer) from the database, or gets the LAST current version when
> there's concurrent access to that object.
>
> 2) Each write in any transaction leads to a new in-memory version of
> the object. This version is also logged in the transaction log.
>
> 3) Each new, concurrent transaction requesting updated objects will
> use the LAST version.
>
> 4) When all concurrent transaction are done (given some closure), the
> last version of each object is committed to the database.
>
> 5) Isolation, if I have analyzed this correctly, is complete simply
> due to multiversioning.
>
> The point is, this is a lock-free concurrency scheme where new
> transaction reads the latest version, and any update will lead to
> short-lived new versions. It appears to work out nice in distributed
> databases as well, with low message-passing overhead, although I
> haven't fleshed out all the details yet.
>
> Any comments on this approach? AFAICT, this is different from
> multi-version databases, yet appears to be a useful approach. Or...?

That sounds like it's much the same as MVCC, with the possible caveat of adding vulnerability to "dirty reads."

-- 
let name="cbbrowne" and tld="acm.org" in name ^ "_at_" ^ tld;;
http://cbbrowne.com/info/sgml.html
"The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program  to work, and getting it  right."
-- M A Jackson, 1975