[infinispan-dev] Conditional cache operations useless with Optimistic locking?

[Dan Berindei]

On Tue, Mar 12, 2013 at 1:32 PM, Galder Zamarreño <galder at redhat.com> wrote:

>
> On Mar 8, 2013, at 1:50 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>
> > Hi Galder,
> > I think using conditional operations is very useful even with
> > optimistic locking: the single conditional operation might not make
> > sense, but a transaction might include more operations and some of
> > these operations might depend on the result of the conditional
> > operation.
> >
> > I'd expect the conditional operation to only return the value based on
> > current state (a prediction), and the transaction would fail if this
> > value is no longer valid at commit time. So no locks need to be taken
> > during the evaluation.
>
> ^ That's indeed what's happening, but as you can see, it confuses users
> (Jim, are you there?)…
>
> And I can see why they get confused. The conditional operations, such as
> replace, are rooted in enabling CAS-like operation, and an attempt to
> replace a value in a collection without having to synchronize or use locks…
>
> You can do what you say above with put/get operations. It will create more
> boiler plate code for sure, but the expectations of what the code does
> might be easier to understand for users.
>
> So, on one side, conditional operations can help reduce the code-size (by
> doing multiple operations in one go), but users expect them to behave in a
> way which does not really happen when you use transactions + OL.
>
> I'm in two minds on this…
>
>
I remember having a discussion about conditional operations with optimistic
locking a long time ago (Edinburgh?) and concluding that they should be
allowed to "lie" - pretend that they did the put/replace/remove and check
again on prepare if the condition still holds (with write skew check
enabled).

I think the other option on the table was treat conditional operations as
"non-transactional" - if putIfAbsent(k, v) returned true, then v would be
stored in the cache even if the current transaction was rolled back.

I don't remember if we considered acquiring locks for conditional
operations even with optimistic locking at the time or not. It would be a
bit of a hack, but it would make a lot more sense than the current
behaviour with the default configuration (optimistic locking with write
skew check disabled, which makes conditional operations pretty much
useless).

Off-topic: is it just me, or is it a little odd that the locking mode is
configured via TransactionConfigurationBuilder and the isolation
level/write skew check are configured via LockingConfigurationBuilder?

Cheers
Dan


Cheers,
>
> >
> > Sanne
> >
> > On 6 March 2013 14:45, Galder Zamarreño <galder at redhat.com> wrote:
> >> Hi,
> >>
> >> Re: https://issues.jboss.org/browse/ISPN-2891
> >>
> >> Not sure what previous Infinispan version the AS instance Immutant guys
> used (5.1?), but seems like they're having more issues with the clojure
> test linked in the JIRA.
> >>
> >> Again, we're talking about issues with replace(), but in a single node
> environment. They seem to have issues with PL and OL, but let's focus on OL
> for which there are logs attached.
> >>
> >> Do conditional operations make any sense at all with OL? For example,
> can the return of replace() be taken a truthful in a transaction with OL?
> >>
> >> As shown in the bad.log, this is not possible because lock acquisition
> and write skew checks are only done when the transaction is committed. So,
> what's the point of the conditional operations with OL? Their returns
> provide no guarantees whatsoever.
> >>
> >> If this is known thing, I'm not aware of any docu on the topic.
> >>
> >> Thoughts?
> >>
> >> Cheers,
> >> --
> >> Galder Zamarreño
> >> galder at redhat.com
> >> twitter.com/galderz
> >>
> >> Project Lead, Escalante
> >> http://escalante.io
> >>
> >> Engineer, Infinispan
> >> http://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
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130312/13730f23/attachment.html