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, 31 Mar 2007 15:14:15 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

------------------------------------------------------------------------------
  ## page was renamed from Brainstorm 2.0
  == This page is a collection of ideas for the Commons Transaction 2.0 version. ==
+ 
+ Is commons transaction usefull at all?
+  * file store is something used in a number of projects
+  * 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
+ 
+ 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
  
  Philosophy:
   * as few dependencies as possible (few external jars)
@@ -34, +51 @@

  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 remote access / administration to a file store
-  * Allow for deadlock detection in its own thread
+   * Allow for deadlock detection in its own thread
   * what else?
  

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


Mime
View raw message