[infinispan-dev] mixing optimistic and explicit locking

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] mixing optimistic and explicit locking

Mircea Markus
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] mixing optimistic and explicit locking

Manik Surtani
I don't think so - since the whole explicit locking cfg option goes away and will be replaced with pessimistic locking, correct?

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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] mixing optimistic and explicit locking

Mircea Markus
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] mixing optimistic and explicit locking

Sanne Grinovero-3
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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> [hidden email]
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] mixing optimistic and explicit locking

Manik Surtani

On 8 Sep 2011, at 11:31, Sanne Grinovero wrote:

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).

Yes, this becomes a separate subject I suppose.  Is there a need for a batching API at all, won't transactions be sufficient?



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] mixing optimistic and explicit locking

Manik Surtani

On 8 Sep 2011, at 14:54, Manik Surtani wrote:

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).

Yes, this becomes a separate subject I suppose.  Is there a need for a batching API at all, won't transactions be sufficient?

Also keep in mind JSR 107 is proposing a concept of "local transactions", which would in effect be the same as batching.



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev