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
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org