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