Jody Garnett a écrit :
> Hopefully when we provide some stress tests we will be able to better
> communicate the motivation for using two sets of locks.
Sigh... One of us is really not understanding the other one point. I claim
again
that *the read lock in ObjectCacheEntry is totally useless* in order to prevent
the same CRS to be built twice in two different threads. Did you understand the
workflow I posted two days ago? (posting again below). Or does my workflow has
a
flaw?
- thread 1 get(key) returns null from cache miss
- thread 1 acquires the lock
- thread 1 starts building the referencing object
- thread 2 get(key) returns null from cache miss
- Thread 2 try to acquire the lock
- Thread 2 block because thread 1 already has the lock
- thread 1 finishes building the referencing object
- thread 1 stores the value in the cache
- thread 1 releases the lock
- thread 2 acquires the lock
- thread 2 realize that the object is already created, because it performs a
second call to get(key) once it hold the lock and this second call returns a
non-null object.
- Thread 2 releases the lock. *Thread 2 has NOT recreated the CRS - it got if
from the cache*
Martin
-------------------------------------------------------------------------
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
