Martin Desruisseaux wrote: > I means, we could apply on BufferedAuthorityFactory the same changes (using > the > object cache) that you applied on ThreadedAuthorityFactory. But by preserving > BufferedAuthorityFactory in its current state (for now), we avoid that such > change (if we decide to apply it) appears in the history as a whole block > deleted, then a whole block inserted. > > ThreadAuthorityFactory would just override 'getBackingStore()' with something > more elaborated than returning a constant backing store. The object cache > mechanism after that would be the same. > I understand your request. The concept of "BufferedAuthorityFactory" is attractive - ie represent "just the concept of owning a cache and delegating to a worker" (as a performance optimization) And keep "ThreadedAuthorityFactory" as another class to represent "owning the cache and sharing it with several workers" (with supporting multiple threads as a new ability).
The problem is these are identical in implementation: even for case of a single worker I am going to store it in an ObjectPool so I can can remove all the Timer concerns about evicting the backingStore. I need to show that am doing what we are paid for - making GeoTools referencing module handle multiple threads (and basically scale). A class name helps me make that point in a clear way everyone can see on a class diagram. Jody ------------------------------------------------------------------------- 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
