Martin Desruisseaux wrote: > I understand the sequence of "readLock()", "writeLock()", "get()" and > "peek()" > you described. My point is that you don't need the read lock at all for > achieving exactly what you want to achieve, and consequently ObjectCacheEntry > don't need to hold a ReadWriteLock, and consequently ObjectCacheEntry itself > may > not be needed.
We are focusing on both concurrency *and* avoiding duplication of work in the construction of the Referencing objects. The get() method should block precisely because a write lock has been obtained and someone is in the process of generating its value. Our designed workflow is as follows: - thread 1 get() returns null from cache miss - thread 1 acquires a write lock - thread 1 starts building the referencing object - thread 2 get() blocks on request for the same referencing object - thread 1 finishes building the referencing object - thread 1 stores the value in the cache - thread 1 releases the write lock - thread 2 obtains the referencing object from the cache As you can see, we need a more complex design to support this -- do you agree with our justification? Cory. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
