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:
Make all parts of the code thread safe
Add tests
Add logging
Add API docs
Add high level docs
Links:
Lots of links by Brian Goetz:
http://www.briangoetz.com/pubs.html Deadlock detection using JMX in JDK 1.6:
https://www.limewire.org/fisheye/browse/limecvs/gui/com/limegroup/gnutella/gui/DeadlockSupport.java?r=1.3 Testing
What Joshua Bloch thinks about API design:
http://www.scribd.com/doc/33655/How-to-Design-a-Good-API-and-Why-it-Matters