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/[EMAIL PROTECTED] - * 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
