On Thu, Sep 17, 2009 at 6:28 AM, Krukow <karl.kru...@gmail.com> wrote: > > > > On Sep 16, 10:06 pm, Rich Hickey <richhic...@gmail.com> wrote: >> On Sep 16, 11:39 am, Stuart Halloway <stuart.hallo...@gmail.com> >> wrote: >> >> > The docs could be more clear, but if validate-fn must be side effect >> > free then it certainly can't look at any other refs. >> >> Yes. The docs should say the function must be pure. While I understand >> the multi-ref validation use case, currently it is not supported. > > Ok, I guess I was thinking of a "side-effect" as something that > *changes* state.
When you take a lock, you change the state of that lock, and that state-change is a side-effect that can be observed by everyone who have access to that same lock :) That, however, is probably easy to forget. Like it is also easy to forget that deref'ing a ref means taking and releasing a read-lock. > But I see that "pure" is really means referentially > transparent in this case (which does not include looking at other > refs). > > I would suggest that the docs are changed to: > > "... validate-fn must be nil or a side-effect-free (referentially > transparent) fn of one > argument, which will be passed the intended new state on any state > change. If the new state is unacceptable, the validate-fn should > return false or throw an exception. validate-fn will be called on > transaction commit, when the ref has its final value. > Validation across multiple refs is currently not supported" > > or some variant of that (not sure the 'referentially transparent' > comment is necessary, although it was helpful for me :-). > > One question I would like to ask is about increasing concurrency in > the use-case I mentioned in this post. In my example I have two > accounts a1 and a2, requiring that @a1 + @a2 >= 0 invariably. A > withdraw transaction that ensures one account, checks that the > invariant holds, and does the withdrawal from the other is really > permitting less concurrency than what is optimal. The call to ensure > prevents/serializes also any concurrent activity which would not > violate the constraint that @a1 + @a2 >= 0, e.g., a concurrent > deposit. > > So it seems that multi-ref validation also has a use-case in terms of > increased concurrency (i.e., retry only if the invariant doesn't > hold)? Any thoughts? > > Final question. The docs say that 'ensure' permits more concurrency > than promoting the ref to a write. Is there a quick/simple way of > explaining how? (Or do I need to go to the source :-) > > Thanks for the clarifications > /Karl > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
