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

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

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

Current status of implementation:

  • Most stuff implemented
  • UndoManager needs serialization (To what? XML?) and is merely non-functional
  • General missing steps:
    1. Make all parts of the code thread safe
    2. Add tests
    3. Add logging
    4. Add API docs
    5. Add high level docs

Links:

  • No labels