On Tue, Mar 12, 2013 at 1:32 PM, Galder Zamarreño <gal...@redhat.com> wrote:
> > On Mar 8, 2013, at 1:50 PM, Sanne Grinovero <sa...@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 <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 > > > -- > 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