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.
Stu > On Sep 16, 11:15 am, Christophe Grand <christo...@cgrand.net> wrote: >> I think you managed to produce a deadlock :-( >> >> thread 1 is commiting and has a write lock on a1 >> thread 2 is commiting and has a write lock on a2 >> thread1 tries to acquire a read lock on a2 (in the validator) and >> blocks >> because thread2 has a write lock on a2. >> thread2 tries to acquire a read lock on a1 (in the validator) and >> blocks >> because thread1 has a write lock on a1. > > Right, my first thought was a loop; but from your analysis, it is > obviously a deadlock. > > I guess the conclusion is that you should not use validators for > inter- > ref validations. However, the documentation simply says: > > "... validate-fn must be nil or a side-effect-free 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 all refs have their final values." > > The last sentence seems to indicate that it is OK to look at several > refs. > > So, yes, we need Rich here ;-) > > /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 -~----------~----~----~----~------~----~------~--~---
