Re: [infinispan-dev] Atomic operations and transactions
On Tue, Jul 5, 2011 at 12:49 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
2011/7/5 Dan Berindei <dan.berindei(a)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?