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. Sanne On 6 March 2013 14:45, Galder Zamarreño <gal...@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 > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev