Thanks Martin - we can use this implementation for testing as well. It looks like it will be a good solution for the non dispatch case. Hopefully when we provide some stress tests we will be able to better communicate the motivation for using two sets of locks. Jody > Martin Desruisseaux a écrit : >> So there is my proposal: I will commit a ObjectCache2 class (without >> any ObjectCacheEntry class) so you can see my point. It will use the >> modified workflow that I tried to explain in my previous email. > > There is the proposal (not commited because it use Java 5 features). > > * No ObjectCacheEntry. > > * Less objects keep around (no Lock objects retained after > the cached object creation). > > * Less locking than the original DefaultObjectCache > during read operation. > > I have not tested; it is just in order to show my point. > > Your previous emails suggest that you think that I didn't understood > your goals. I believe that I understood your goals from the begining, > but that I have been unable to explain why I believe that a > ReadWriteLock in ObjectCacheEntry is an unneeded overhead for your > goals. Please read again my "modified workflow" in my yesterday email, > and I would appreciate if you can point me a flaw in this workflow > regarding your goals. > > 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
