[infinispan-dev] Atomic operations and transactions

[Dan Berindei]

On Tue, Jul 5, 2011 at 12:49 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>
> 2011/7/5 Dan Berindei <dan.berindei at 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?