On 15 Jul 2013, at 17:22, Ales Justin <ales.justin(a)gmail.com> wrote:
>> So you're saying that while this state transfer was going
on, some other process (another thread) changed this value?
>
> The functionality I've described is not related to the state transfer in
particular, but has to do with how optimistic transactions work.
> Was there a state transfer in progress anyway? (hard to determine that from the
thread dump)
Afaik, the exception is thrown on the other node, which received the update.
The funny thing is that we haven't seen this before.
e.g. we had manual clustering tests, running w/o problems,
now we're finally moving (thanks Rado!) to fully automated clustering tests,
yet we (aka Matej) get this exception
>>
>> Any way to avoid this?
>> Global lock is fine, for now.
>
> You can always disable write skew check (<locking
writeSkewCheck="false"/>) . That would allow the transaction to succeed even
if the value has changed in between the read time and commit time. But that's only if
your application can live with that, i.e. an application specific decision.
We need skew check since we use Infinispan's versioning.
I assume you have concurrent access to the same infinispan key then?
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)