On Jul 15, 2013, at 6:33 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
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?
Instead of going backwards/forwards with questions, TRACE logging on org.infinispan
(attach file, not paste) on all nodes, and pointing to the test to replicate the issue
would help from the start, really :)
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org