[infinispan-dev] [ISPN-78] Feedback needed

[Olaf Bergner]

-------- Original-Nachricht --------
> Datum: Tue, 19 Apr 2011 11:06:50 +0200
> Von: "Galder Zamarreño" <galder at redhat.com>
> An: infinispan -Dev List <infinispan-dev at 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#comment-12586154
> > [2] https://github.com/infinispan/infinispan-sample-module 
> > --
> > Manik Surtani
> > manik at jboss.org
> > twitter.com/maniksurtani
> > 
> > Lead, Infinispan
> > http://www.infinispan.org
> > 
> > 
> > 
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at 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 at 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