I thought the validator just set "Agent has errors" and you have to check it explicitly.
Tom 2009/1/27 MikeM <michael.messini...@invista.com> > > > > Were watchers synchronous, they would have to run post-transaction > > (else a watcher action failure could cause a transaction rollback, > > leaving already notified watchers confused). Being post-transaction > > would mean that the refs could have been changed by another > > transaction in the interim. > > I've been looking at the source to make sure I understand the trade- > off you're describing. In LockingTransaction, ref.notifyWatches is > called immediately after ref.validate for each ref. So it seems that a > watcher could be triggered with a value that then gets rolled back if > a subsequent validator throws. So even with the current watcher > implementation, a watcher could be called with a value that is not > consistent with the actual value of the ref when the transaction is > done. This doesn't seem much different from the scenario you're > describing. Is this correct? > > > > > So, to answer your question, no, watchers don't have to be agents, and > > while there would be some tighter guarantees were they not, there's no > > getting around the essential asynchrony of a multi-threaded system. > > After looking at how validators and watchers are invoked, I'm thinking > the current implementation already provides both synchronous and > asynchronous notification - synch notification via a validator, and > asynch notification via a watcher agent. Of course, the validator > isn't intended to be used as a watcher, but I wonder if you could > generalize the notion of validator so that this is acceptable usage. > The value provided to the validator may not represent the actual value > post-transaction (due to roll-back), but this is the cost of getting > synchronous notification. The watcher notification could be moved to > post-transaction, with the possibility that another transaction could > occur before the watcher runs, but this is the cost of asynch > notification. > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
