-------- Original-Nachricht --------
Datum: Tue, 19 Apr 2011 11:06:50 +0200
Von: "Galder Zamarreño" <galder(a)redhat.com>
An: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
Betreff: Re: [infinispan-dev] [ISPN-78] Feedback needed
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?
>
As to locking I currently think that locking metadata will probably suffice. Right now I
started thinking about how to eventually implement transactions. Currently a transactions
accumulated state is retained until it is finally prepared/committed, correct? When
involving large objects this may well blow up the originator node's cache. I thought
about preparing transaction branches storing chunks immediately (without waiting for the
transaction to complete but haven't yet thought about the implications. This might
require some eager locking, though. Any thoughts on this.
As to reusing existing commands instead of creating new ones: I originally intended to do
so yet the deeper into implementing I got the more I came to the conclusion that a custom
command would be more appropriate. The alternative would be to parameterize an existing
command, effectively telling it that it is dealing with a large object. This might get
messy if more and more requirements need to be implemented.
> 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
I wasn't aware of this possibility. It should be relatively easy to port my current
solution to that extension mechanism if the need arises.
Cheers,
Olaf
>
> Cheers
> Manik
>
> [1]
https://issues.jboss.org/browse/ISPN-256?focusedCommentId=12586154#commen...
> [2]
https://github.com/infinispan/infinispan-sample-module
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Lead, Infinispan
>
http://www.infinispan.org
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren:
http://www.gmx.net/de/go/freephone