On Tue, Jul 5, 2011 at 12:49 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > > 2011/7/5 Dan Berindei <dan.berin...@gmail.com>: >> >> After all Sanne has two use cases for atomic operations: sequences and >> reference counts. Sequences can and should happen outside >> transactions, but as we discussed on the train we could make each >> node/thread acquire a range of say 100 seq numbers at a time and >> remove the need for any locking to get a new sequence number. >> Reference counts on the other hand should remain inside the >> transaction, because you would have to to the refcount rollback by >> hand (plus I don't think you should let other transactions see the >> modified refcount before they see the new data). > > To clarify my use case, I'm never going to need refcounts together to > a running transaction. The refcount example was about why I need > atomic counters, but this thread is about the dangers of exposing > these atomic operations API which are broken when using transactions. >
O, I understand refcounts are not really the topic you wanted to talk about, but I'd really like to know why you don't need transactions with refcounts. I was assuming the refcount is a link from a key A in the cache to another key B, so adding another link would involve incrementing the counter as well as adding the key A. Or do you mean that refcount increment/decrement should be a special operation that never fails, so it could be done after the commit of the tx that added key A? _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev