[infinispan-dev] mixing optimistic and explicit locking

[Sanne Grinovero]

Hello,
I think that what is being proposed here is reasonable in the scope of
configuring transactions, but since this will apply to batching too I
think it's going to get some unexpected and undesired behaviour there.

When starting a batch I won't expect it that every put I do is going
to acquire a remote lock until I end the batch, so I'll assume that
when I enable batching Infinispan is going to use an optimistic
locking strategy which shall not fail writes, just allow overwriting
of existing values. Is this the case, is batching going to be
"remapped" to optimistic locking?

The best need for locking during a batch operation is to make sure we
write a consistent value across each replicas; but in addition to that
I would expect lock() to work as usual, if that's not possible l don't
think it's a big issue as it's something the user can compensate for,
but this behaviour should be clarified.

Another kind of issue is using my favorite operations: putIfAbsent,
replace, ... these all should trigger and immediate RPC is needed,
possibly flushing any other pending operation in the same batch.

I think I can work around most differences by changing code using the
API, so this is not a big issue as long as behaviour is well
documented, but also in the long term batching should be reimplemented
in a different way: it seems we're stretching it too much for it's
significantly different use cases.

Since it turns out quite often to explain "weird things" to users
about batching that it is in fact just a DummyTransaction, maybe it
should be better to remove the current batching API and have people
deal explicitly with transactions (in all it's aspects from usage,
expectations and configuration).

Sanne


On 8 September 2011 11:00, Mircea Markus <mircea.markus at jboss.com> wrote:
> On 7 Sep 2011, at 19:25, Manik Surtani wrote:
>
>> I don't think so - since the whole explicit locking cfg option goes away and will be replaced with pessimistic locking, correct?
> This will be deprecated:
>      configuration.fluent().transaction().useEagerLocking(true);
> and replaced by:
>      configuration.fluent().transaction().lockingMode(LockingMode.PESSIMISTIC)
>
> Do we want to forbid[1] cache.getAdvancedCache().lock(k)/unlock(k) when the cache is running in optimistic mode?
> I'm very tempted to say yes, just because this would mean mixing optimistic and pessimistic locking which might end up in very complex user and maintenance scenarios.
>
> Cheers,
> Mircea
>
> [1] if so we can deprecate these methods as we already achieve the same functionality in the case of pessimistic locking by using Flag.FORCE_WRITE_LOCK
>
>>
>> On 7 Sep 2011, at 17:55, Mircea Markus wrote:
>>
>>> Hi,
>>>
>>> Do we want to support explicit locking within optimistic locking scheme? This is something that is currently supported, i.e. one can used the advanced cache's lock method on an optimistic cache.
>>> My concern is mainly related to the existing use cases, is there a need for allowing this?
>>>
>>> Cheers,
>>> Mircea
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>