Table of content:
1 Project Description
Student: Wensheng Dou
Mentor: Ralf Joachim
Since Java 5, Java has introduced the java.util.concurrent API , which supports flexible locking constructs, more concurrent mechanism, and many lock-free and thread-safe atomic data structure. But the Castor project has not supported java.util.concurrent API yet. In the Castor JDO module, the LockEngine implements the read/write lock, and use custom lock mechanism. So the LockEngine is very complicated and error-prone. The “Refactor Lock Engine” project will refactor the Castor to support the java.util.concurrent API, and make LockEngine more readable and maintainable, and repair some concurrency bugs.
2 The ideas
2.1 Refactor the ObjectLock class (CASTOR-3085)
The ObjectLock class uses custom mechanism to implement the read/write locks, and it is too complicated and error-prone. I’ll use the java.util.concurrent.locks.ReentrantReadWriteLock to refactor the ObjectLock class.
- Refactor some variables’ names to make them more intuitive.
- Use HashSet to simplify the LinkedTx.
- Invetigate the meaning of the property _deleted, and then simplify the meaning of the property _deleted (CASTOR-3121)
- Use ReentrantLock and Condition to replace the old wait() and notify(); (CASTOR-3122)
2.2 Refactor the LockEngine class
- LockEngine takes too much responsibility, some functions should be separated.
- LockEngine is too complicated, and there are some concurrency bugs which are difficult to repair, so it should be refactored.
- Eliminate the synchronized on basemolder in in LockEngine.load() (CASTOR-3109)(CASTOR-3119)(CASTOR-3120)
Why: Deadlock causes by sync block in LockEngine.load
(1) Change the oid's meaning, and make it unique for one instance (no matter extended or not). Then one instance just has one oid, just one lock. (CASTOR-3119)
(2) Move registration of entity at TransactionContext to a later point in the process when we already know the correct class? (CASTOR-3120)(CASTOR-3140)(CASTOR-3141)
(3) Just register the entity into TransactionConetxt once. (CASTOR-3148)
- Eliminate double loading of extends hierarchy (CASTOR-3074)
Why: When an extended object is loaded as the base object, the first loading will know what the concrete class is, and then the second loading will load the extended object. It is a performance problem.
(1) When the concrete class is determined, the we return the right objects. (Accepted)
(2) Store the result fields when the first loading finishes, the second loading just molds the concrete instance. (Rejected)
2.3 Remove the EDU.oswego.cs.dl.util.concurrent library (CASTOR-3050)
Since Java 5, Java has introduced the java.util.concurrent API, which supports ReentrantReadWriteLock. But Castor has not used the java.util.concurrent API to improve the performance. The Castor should be compiled on JDK 1.5 (or higher). We should convert the Castor to use java.util.concurrent API, and benefit from the java.util.concurrent package's improvement.
2.4 Replace Hashtable and synchronized HashMap by ConcurrentHashMap to improve cache performance (CASTOR-2940)
In the org.castor.cache.* cache implementations Hashtable and synchronized HashMap will be used as underlying data structures. This issue will use ConcurrentHashMap, ReentrantReadWriteLock and so on to improve the cache performance.
- Improve synchronization/locking at org.castor.cache.* (CASTOR-3154)(CASTOR-3155)(CASTOR-3156)(CASTOR-3158)(CASTOR-3170)
- Add some multithreaded tests for org.castor.cache.hashbelt.* (CASTOR-3176)
- Improve extends hierarchy of caches (CASTOR-3179)
- Use generics at Cache interface (CASTOR-3180)(CASTOR-3186)
2.5 Some other bugs
- ArrayIndexOutOfBoundsException occurs when loading an extended object (CASTOR-3065)
- Delete and the insert with same id in the same transaction fails (CASTOR-1044)
- Some inconsistent errors between pom.xml and .classpath (CASTOR-3051)
- A maven building error : castor-xml has dependency on castor-codegen (CASTOR-3048)
3 Related JIRA tasks