Martin Desruisseaux wrote: > It can be a DirectAuthorityFactory, but also a AuthorityFactoryAdapter > which doesn't extends DirectAuthorityFactory... Good point. >> This contract is the same for both classes on the table; the code >> will be the same at the end of the day; are you wanting to change the >> configuration parameters of the pool? So BufferedAuthorityFactory >> only keeps one worker (ie a single BackingStore) and >> ThreadedAuthorityFactory has access to many? > * BufferedAuthorityFactory.getBackingStore() would just returns > the backing store specified at construction time; this is a > singleton. BufferedAuthorityFactory would not manage any ObjectPool. > DeferredAuthorityFactory would continue to extends > BufferedAuthorityFactory > (we may deprecate this class anyway, so its fate is not really a > concern). Okay I understand; I will break this up into two classes then... - BufferedAuthorityFactory which is abstract - DelegateAuthorityFactory which wraps up a single delegate > * ThreadedAuthorityFactory add an ObjectPool and override the > getBackingStore() in order to returns a factory from this pool > rather than a factory specified at construction time. - ThreadedAuthorityFactory (similar to DeferredAuthorityFactory in that it connects in a lazy manner to one or more backingStores, even in the case of a single backingStore an ObjectPool is used). The implementation may be configured to use many backingStores when under heavy load...
> Yes a see BufferedAuthorityFactory as a simple wrapper around a single > backing store, and ThreadedAuthorityFactory as an extension for more > advanced cases. Are you okay with me splitting them out as described above? When doing the wrapper thing we are constructed with the backingStore - it is a different use case with no eviction policy. > A simple wrapper as around a single backing store may be what some > users want when building a simple factory. For example a factory > backed by WKT. Do we want the whole WKT file to be loaded by each > factory instance? With a simple wrapper around a single backing store, > the user is not faced to this issue. With ThreadedAuthorityFactory, he > need to think about that. I am still interested in using object pool in this case; so we can evict the wkt reader when it is not used (so we can free up all that room taken up in memory by the property file). It is too bad the WKT property file could not be shared by several workers in order to handle a more serious load. Something we can think about if a profiler tells us it is an issue. > You seem to believe that "ThreadedAuthorityFactory extends > BufferedAuthorityFactory" will be a cause of difficulties or code > duplication... I though that it would be something easy to do, > separate concerns easily (with real value added in > ThreadedAuthorityFactory, like the ObjectPool which would be declared > there) and provide something easier than ThreadedAuthorityFactory for > user who just want buffering... Understood; you have explained the separation of concerns now - I will make sure a concrete class exists to capture each one. > If you feel that you don't have time to sort that out for now, please > just ignore. I can revisit later according what I will see in > ThreadedAuthorityFactory. Thanks Martin, I am sorry about the time crunch (I really wished we started doing these renames on day 3 of the proposal as this has been a very useful discussion). Perhaps we should narrow the proposal acceptance period down from the current 15 days? Cheers. 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
