"genman" wrote:
It's nice that things are simpler and eviction by TTL is a "first class" strategy.
Yeah expiration and eviction being bundled together was a bit clunky. :-)
"genman" wrote:
* As a user consulting the JavaDoc, it's not readily apparent how to construct a cache instance. "factories" is not a bad guess but there's a lot of classes in there and I got a bit lost. I would probably have the DefaultCacheFactory moved to org.infinispan.CacheFactory . I think "Default" is self-evident if there's only a single type of CacheFactory out there :-) A builder method that also took an XML filename would be useful for users as well.
Hmm, thanks for your feedback here. The CacheFactory is
not the way you construct the cache. As such I should rename the class so it isn't misleading. The correct approach is to use the CacheManager. Making the javadocs clearer in this regard is something I still need to do. In the meanwhile, have a look at
http://www.jboss.org/community/wiki/5minutetutorialonInfinispan which shows cache construction and usage.
"genman" wrote:
* Noticed a mix of plural and singular package names, e.g. "factories" but not "loader". Not sure going singular for everything makes sense but would at least be consistent.
Some of this is leftover from JBC, but you are correct in that this is the time to correct such things without fear of breaking compat.
"genman" wrote:
* Package is org.infinispan.loader ... Maybe just a design idea but do the streaming load/store operations really support infinite capacity in practice? I was thinking an entry iterator would work better than a byte stream, in terms being able to distribute the memory storage.
Internal buffering may be used by implementations. The reason why I don't want to use an Iterator is that it implies that state is deserialized and as such this makes certain optimizations impossible, for example transferring state from node 1's store to node 2's store. There should be no reason to deserialize this stream.
"genman" wrote:
* Flag.UNSAFE_UNRELIABLE_RETURN_VALUES is a little long for a flag name, I think. Maybe something like "IGNORE_OLD_VALUE" or something like that.
This has already been replaced in post-ALPHA2 code to SKIP_REMOTE_LOOKUP (
http://tinyurl.com/dbnr5w) since its scope has expanded to simply trying to do a get() but not wanting to consult remote nodes.
"genman" wrote:
Package-level JavaDoc would be helpful in identifying which packages were internal functionality or not. These days you can create a "package-info.java" and simply document using JavaDoc comments.
This is TBD.
Thanks for your comments!
