On 19 Apr 2011, at 10:06, Galder Zamarreño wrote: > > On Apr 18, 2011, at 12:35 PM, Manik Surtani wrote: > >> >> On 15 Apr 2011, at 18:00, Olaf Bergner wrote: >> >>> Am 15.04.11 16:56, schrieb Manik Surtani: >>>> On 11 Apr 2011, at 13:13, Galder Zamarreño wrote: >>>> >>>>> - Rather than modifying PutKeyValueCommand, it might be better to >>>>> subclass it and add the large object logic there? i.e. >>>>> PutLargeKeyValueCommand - I'd also suggest adding a new build* method in >>>>> the command factory...etc. This keeps the code more fine grained. >>>> I don't understand why you need a specialised PutKVCommand? How is >>>> behaviour different? >>> In its present shape PutKVCommand will *always* attempt to read the >>> given key's value before proceeding to store the new value. I doubt that >>> we need this for large objects. To determine if we are to perform a >>> create or an update it suffices to consult the metadata cache. We won't >>> be returning the former value anyway. >> >> Understood. Even locking semantics would be different since you only >> acquire the lock on the metadata entry and not on each and every chunk. >> Correct? >> >> So I presume you are building this as a separate Maven module, and making >> use of the module-specific commands as described here [1] and [2] ? > > Why would he need a separate module? He's not bringing any new dependencies > AFAIK Also large objects don't look orthogonal to the existing functionality ( e.g. like the server are) but more like a core thing, like e.g. explicit locking. OTOH I think that these (large objects, eager locking) are features to be used by "power users" and not necessarily to be exposed on the o.i.Cache interface. So an interface within the same module, perhaps even extending o.i.Cache would make more sense to me.
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
