On Mon, Feb 23, 2009 at 6:23 PM, Rich Hickey <richhic...@gmail.com> wrote: > > 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"
Thanks for trying to explain this. I apologize for taking so long to understand it. Perhaps the guarantees are purposely vague to avoid guaranteeing too much. My question is focused on timing. Above it says "should a transaction have a conflict" and "it is automatically retried". I'm trying to understand *when* it realizes there is a conflict and *when* it retries. I suspect it realizes the conflict when it tries to set a new in-transaction value. I suspect it retries immediately rather than waiting from some other event to occur. I'm just trying to verify my guesses. > 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." -- R. Mark Volkmann Object Computing, Inc. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
