commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-commons Wiki] Update of "Brainstorm Transaction 2.0" by OliverZeigermann
Date Sat, 28 Jul 2007 22:09:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by OliverZeigermann:
http://wiki.apache.org/jakarta-commons/Brainstorm_Transaction_2%2e0

------------------------------------------------------------------------------
   * with the increasing number of processor cores per machine there is an increasing need
for concurrent programming
   * concurrent programming is still an art, not a science or solved field of engineering:
people need support
  
+ General improvements over 1.x:
+  * Make code much cleaner and more obvious
+  * Cleanly define interfaces
+  * Use 5.0 features like generics and locks
+  * Use file channels
+  * Use commons logging
+  * Full file management capabilities for transactional file system
+  * Much improved transaction scheme
+  * Mimimize depdendencies
+  * Further reduction of deadlock likelyhood
- Why a new major version in the first place? (aka Limitations of 1.x)
-  * file store implementation is prone to deadlocks:
-   * not caused by any bugs
-   * rather because there are blocking locks that might turn into live locks if a transaction
never gets committed
-   * solution might require an optimistic (non-blocking) locking scheme
-  * implementation is a bit "weird" at times
-  * aim of 1.x was not clearly defined
-  * does not use Java 1.5 concurrent classes
-  * usefulness of certain parts is questionable
-  * certrain parts of implementation lack a satisfying correctness test
-  * interface/implementation philosophy is inconsistent
  
+ Use cases for 2.0:
+  * Use the lock manager and hierarchical lock maanger for your own applications
+   * Benefit from automatic deadlock recovery
+   * Make sure your code is always interruptable
+   * Let your code have a timer for a whole block of locks
+   * Be sure you never forget to release a lock again
+  * Have transactional file access
+  * Have a framework to add transactionality to all kinds of resource managers
+  * Have a transactional map implementations
+  * Have a whole set of set of transactional implementations taking part of a single transaction
- Philosophy:
-  * as few dependencies as possible (few external jars)
-  * require Java 1.5 
-  * optionally use 1.6 as it really adds nice concurrent stuff including
-   * JMX access to concurrency internals and diagnostics
-   * some new concurrent collections
-  * use java.util.concurrent
-  * use a different package name (e.g. o.a.j.c.transaction2)
-   * discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/%3C454926B6.1020703@btopenworld.com%3E
-  * maybe supply a 1.x compatibility package
-  * only implement a core that does the transactional part
-   * leave the rest to optional modules and custion implementations by calling exchangeable
implementation of interfaces
-   * use Spring for configuration
-   * modules
-    * How does a transaction map to temporary data
-    * Where is temporary data and final data stored (maybe use VFS?) 
-    * Id generator
-    * What else?
-  * have a default implementation 
-   * for all required modules 
-   * keep it slim and rudimentary
-   * amounts to a transactional file store out of the box
  
+ Current status of implementation:
+  * Most stuff implemented
+  * UndoManager needs serialization (To what? XML?)
+  * Transactional file access needs more fain grain undo logging for bulk copy/move/delete
operations
+  * General missing steps:
+   1. Make all parts of the code thread safe 
+   1. Add tests
+   1. Add logging
+   1. Add API docs
+   1. Add high level docs
- Features of transaction implementation:
-  * a transaction is defined by a set of locks, a timeout and some sort of resource manager
-  * supply a watchdog thread that takes care of deadlocks and timed out transaction
-  * when a transaction is rolled back
-   * the resource manager is told to roll back all changes 
-   * all locks of the lock set are freed
- 
- Features of the file resource manager implementation:
-  * allow for additional guaranteed deadlock free actions on resources
-   * move and tree-move
-   * copy and tree-copy
-   * delete and tree-delete
-  * maintain an explicit tree (graph?) structure
-  * provide an administration interface based on JMX
-  * change the transaction scheme to perform actions as they are requested and maintain a
roll back log. In case of commit nothing will be done, in case of a rollback all changes will
be reverted according to the roll back log. Eventually, all locks will be released.
- 
- Testing:
-  * Testing should be based on JUnit 4
-  * Maybe http://findbugs.cs.umd.edu and MTC could also be helpful
-  
- Open Questions:
-  * Is Jakarta Commons the right place for such a project?
-  * Should we introduce threading in order to
-   * Allow remote access / administration to a file store
-   * Allow for deadlock detection in its own thread
-  * Would an implementation of the JSR 170 (JCR) level 1 make sense (http://jackrabbit.apache.org/doc/arch/overview/jcrlevels.html)?
-  * what else?
  
  Links:
   * Lots of links by Brian Goetz: http://www.briangoetz.com/pubs.html
@@ -78, +48 @@

    * http://www-128.ibm.com/developerworks/java/library/j-jtp08226.html
    * http://www-128.ibm.com/developerworks/java/library/j-contest.html
   * What Joshua Bloch thinks about API design: http://www.scribd.com/doc/33655/How-to-Design-a-Good-API-and-Why-it-Matters
+  * http://findbugs.cs.umd.edu 
  
- Finally: Is this really worth the hassle?
-  * Cons
-   * This is tough work.
-   * Who is going to use this? 
-   * It will be really hard to get it error free.
-   * Is the team really up to the task?
-  * Pros
-   * Might be fun to do.
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message