RE: [Jdbm-developer] Preliminary work on version manager is ready to commit...

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

Kevin,

 

Sounds interesting.  I just fixed the deadlock detection code and integrated
it into the 2PL locking support[1].  This does not support intention locks
(you can not describe a hierarchy of resources), but it should support basic
2PL.  I am working on an optimization to the deadlock detection code and I
hope to release a beta by Monday.

 

I take it that you mean that the notion of consistency for the design that
you have does not use any notion of transactions within a page manager layer
such as DBCache.  Is that of necessity or just how you developed it?  The
DBCache [2] implementation will let you force a page to the db at any time,
but that is probably not what you are looking for.  In any case, I am sure
that we will get a chance to discuss the relationship between the
version/transaction manager and page caching :-)

 

I am not sure how best to proceed with respect to a jdbm2.x code base.
Anything that is derived from jdbm1.x is of course under the existing
license terms, but new modules can be under a different license as long as
they do not share code or have explicit copyright grants from all authors. 

 

-bryan

 

[1]
http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-concurrent/ind
ex.html
<http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-concurrent/in
dex.html> 

[2] http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-dbcache
<http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-dbcache%20/in
dex.html>  /index.html

 

 

  _____  

From: jdb...@li...
[mailto:jdb...@li...] On Behalf Of Kevin Day
Sent: Thursday, March 23, 2006 10:16 AM
To: JDBM Developer listserv
Subject: [Jdbm-developer] Preliminary work on version manager is ready to
commit...

 

Gents-

 

OK - finally had time to finish up work on the proof of concept for the
version and transaction manager for jdbm2.  This is just proof of concept,
but I'd like to ask you guys to take a look at the unit test and let me know
if you see anything that you think should be tested for that isn't, etc...

 

The current implementation has been tested for transaction isolation for
overlapping transactions, properly purging of unneeded data, etc...

 

The algorithm has been designed with aborts and roll-back in mind, but I
have not put unit tests in place for that yet (tomorrow maybe), and the code
for properly purging aborted tx from the transaction manager still needs to
be put in place (Basically, aborted tx can't be removed from the master
transaction list until the garbage collector has run one full iteration).

 

The algorithms are designed to allow writing to the data store at any point
- regardless of whether a transaction is comitted or not.  A warning:  this
is *very* different from the dbCache design, which relies on only writing
comitted data to the data store (or jumping through hoops to allow for
roll-back if uncomitted data is written to the store).

 

The current proof of concept system has no caching - all changes to the data
are written directly to the store (which is in-memory right now - nothing to
disk, etc...).  This means that there is absolutely no distinction between
regular transactions and very long transactions - the algorithm treats them
all the same (and works :-)  ).  This means that handling of VLR will become
a caching policy implementation detail - not something that requires special
handling in the transaction or version managers (this is a good thing, I
think).

 

 

So - where should I commit the code to?  Alex - should I create a separate
folder for jdbm2 exploratory stuff in the jdbm SF project?  Should we create
a new SF project (for licensing reasons)?

 

Thanks,

 

- K

 

 

Kevin Day
Trumpet, Inc.
www.trumpetinc.com <http://www.trumpetinc.com> 
ke...@tr... <mailto:ke...@tr...> 
602-438-7030

 

------------------------------------------------------- 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