On Feb 23, 2009, at 4:47 PM, Mark Volkmann wrote:
> > On Mon, Feb 23, 2009 at 3:19 PM, Rich Hickey <richhic...@gmail.com> > wrote >> >> On Feb 23, 2009, at 3:44 PM, Mark Volkmann wrote: >> >>> On Mon, Feb 23, 2009 at 2:31 PM, Dan <redalas...@gmail.com> wrote: >>>>> If I understand correctly, when there is an attempt to modify a >>>>> Ref >>>>> that has been modified in another thread since the current >>>>> transaction >>>>> began then the current transaction will retry immediately. Isn't >>>>> it >>>>> true that it has no chance of completing until the transaction >>>>> that >>>>> changed that Ref either commits or rolls back? If that is true, >>>>> wouldn't it make sense to make the retry wait until that other >>>>> transaction is finished? Maybe the point of retrying immediately >>>>> is >>>>> that it can at least get through some of its work (the part before >>>>> it >>>>> tries to change the Ref in question) before it has to check on >>>>> that >>>>> other transaction again. >>>> >>>> Until there is a commit, no one but the transaction knows that >>>> those refs >>>> are meant to hold new values. >>> >>> Ah ... I didn't know that. I did know that the new value wasn't >>> visible outside the uncommitted transaction, but I thought other >>> transactions were aware that some other transaction was changing it. >>> Thanks for explaining that! >>> >>>> When your transaction notices something is >>>> wrong and retries, the other transaction will *always* be finished. >>>> Which of >>>> course doesn't mean another transaction might not prevent it to >>>> finish >>>> again. >>> >> >> This stuff is not right. >> >> You really shouldn't be concerned about the details of what happens >> when *inside* a transaction. The guarantees of http://clojure.org/ >> refs >> are met, but the exact flow can get complex - there is blocking, >> deadlock avoidance and conflict resolution, aging and barging etc. >> >> I frequently see these "this happens then that happens" imaginings >> about what happens inside transactions. Nothing other than what is >> documented is guaranteed, and those guarantees are about what a >> transaction sees, and what its effects are on commit, not the order >> of >> operations inside a transaction. >> >> If you're not doing side effects in transactions, you shouldn't care, >> and you shouldn't be doing side effects in transactions. > > Without getting into the implementation details, is there anything > wrong with this statement? > > While in a transaction, if an attempt is made to modify a Ref > that has been modified in another transaction that has committed > since the current transaction started, > the current transaction discards all its in-transaction Ref > changes > and retries by returning to the beginning of the dosync body. > > -- > The answer is here: http://clojure.org/refs "should a transaction have a conflict while running, it is automatically retried" and "3. No changes will have been made by any other transactions to any Refs that have been ref-set/altered/ensured by this transaction." Rich --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
