On 19 Apr 2011, at 12:05, Olaf Bergner wrote: > 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.
Well, if you store a chunk before the tx completes, handling a rollback could be tough. Eager locking too would need to change to also push the modification eagerly. Vladimir should have some thoughts around 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. Pros and cons. Much cleaner to have your own command (or a subclass), I agree. But it means much more visitor methods which can get messy. Hence my suggestion to use a separate module. But this isn't that important for now, as you point out. Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
