Refactor Lockengine


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.

  1. Refactor some variables’ names to make them more intuitive.
  2. Use HashSet to simplify the LinkedTx.
  3. Invetigate the meaning of the property _deleted, and then simplify the meaning of the property _deleted (CASTOR-3121)
  4. Use ReentrantLock and Condition to replace the old wait() and notify(); (CASTOR-3122)

2.2 Refactor the LockEngine class

  1. LockEngine takes too much responsibility, some functions should be separated.
  2. LockEngine is too complicated, and there are some concurrency bugs which are difficult to repair, so it should be refactored.

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.

  1. Improve synchronization/locking at org.castor.cache.* (CASTOR-3154)(CASTOR-3155)(CASTOR-3156)(CASTOR-3158)(CASTOR-3170)
  2. Add some multithreaded tests for org.castor.cache.hashbelt.* (CASTOR-3176)
  3. Improve extends hierarchy of caches (CASTOR-3179)
  4. Use generics at Cache interface (CASTOR-3180)(CASTOR-3186)

2.5 Some other bugs

  1. ArrayIndexOutOfBoundsException occurs when loading an extended object (CASTOR-3065)
  2. Delete and the insert with same id in the same transaction fails (CASTOR-1044)
  3. Some inconsistent errors between pom.xml and .classpath (CASTOR-3051)
  4. A maven building error : castor-xml has dependency on castor-codegen (CASTOR-3048)

3 Related JIRA tasks