RE: re[10]: [Jdbm-developer] re[2]: DefaultTransactionManager - d r aft of prototype.

[Thompson, B. B. <BRY...@sa...>]

So, locking imposes an ordering constraint on the execution of transactions
but the data view is governed by MVCC?

 

  _____  

From: jdb...@li...
[mailto:jdb...@li...] On Behalf Of Kevin Day
Sent: Tuesday, April 04, 2006 1:00 PM
To: JDBM Developer listserv
Subject: re[10]: [Jdbm-developer] re[2]: DefaultTransactionManager - dr aft
of prototype.

 

Bryan-

 

Locking provides transaction serialization isolation only.  Read
Uncommitted, Read Committed and Repeatable Read are entirely provided by the
MVCC layer.

 

- K

  


 

> 
Expand on this please.  What is the role fulfilled by locking in this
design? -bryan 
 


From: jdb...@li...
<mailto:jdb...@li...>
[mailto:jdb...@li...]
<mailto:jdb...@li...>  On Behalf Of Kevin Day
Sent: Tuesday, April 04, 2006 10:40 AM
To: JDBM Developer listserv
Subject: re[8]: [Jdbm-developer] re[2]: DefaultTransactionManager - dr aft
of prototype. 
 

Bryan- 

 

This is completely different with MVCC.  Transactions operate in complete
isolation from each other, regardless of what type of locking you use. 

 

In the proof of concept I've put together, you can release locks whenever
you want without violating isolation.  Locking is only necessary to ensure
serializability. 

 

Nice, eh? 

 

- K 

  
<SNIP>
 
<
<

 

------------------------------------------------------- This SF.Net email is
sponsored by xPML, a groundbreaking scripting language that extends
applications into web and mobile media. Attend the live webcast and join the
prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________ Jdbm-developer mailing list
Jdb...@li...
https://lists.sourceforge.net/lists/listinfo/jdbm-developer